Problem Statement
When telemetry = true (the default) is set, the Sentry Gradle plugin evaluates two ValueSource
instances during the configuration phase that spawn two sentry-cli processes:
SentryCliInfoValueSource: executes sentry-cli infoSentryCliVersionValueSource: executes sentry-cli --version
Because these ValueSources are .get()ed during configuration (inside SentryTelemetryService.paramsWithExecAvailable()), Gradle tracks them as configuration inputs. On every configuration-cache-hit build, Gradle re-evaluates all tracked configuration inputs to check if the cache is still valid. This means both sentry-cli processes are spawned on every single build, even when the configuration cache is hit and even when no Sentry tasks execute.
In our production Gradle project (~100 modules), this adds ~38% overhead to configuration-cache-hit builds (measured with gradle-profiler). Setting telemetry = false eliminates the overhead.
Our current workaround therefore is to enable telemetry only on CI. Another would be to don't apply Sentry Gradle Plugin for local builds.
However, in my opinion the real fix would be to find a implementation in the Sentry Gradle plugin which mitigates that the sentry-cli processes are executed on every build again.
Solution Brainstorm
No response
Problem Statement
When
telemetry = true(the default) is set, the Sentry Gradle plugin evaluates twoValueSourceinstances during the configuration phase that spawn two
sentry-cliprocesses:SentryCliInfoValueSource: executessentry-cli infoSentryCliVersionValueSource: executessentry-cli --versionBecause these ValueSources are
.get()ed during configuration (insideSentryTelemetryService.paramsWithExecAvailable()), Gradle tracks them as configuration inputs. On every configuration-cache-hit build, Gradle re-evaluates all tracked configuration inputs to check if the cache is still valid. This means bothsentry-cliprocesses are spawned on every single build, even when the configuration cache is hit and even when no Sentry tasks execute.In our production Gradle project (~100 modules), this adds ~38% overhead to configuration-cache-hit builds (measured with gradle-profiler). Setting
telemetry = falseeliminates the overhead.Our current workaround therefore is to enable telemetry only on CI. Another would be to don't apply Sentry Gradle Plugin for local builds.
However, in my opinion the real fix would be to find a implementation in the Sentry Gradle plugin which mitigates that the
sentry-cliprocesses are executed on every build again.Solution Brainstorm
No response