Telemetry ValueSources cause Configuration Phase Overhead

[SebastianHeil]

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 info
• SentryCliVersionValueSource: 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

[linear-code]

GRADLE-82

[romtsn]

@SebastianHeil thanks for investigating and reporting the issue! We'll see what we can do about this (at least maybe not call to the cli when none of the sentry tasks are going to run). I guess having this feature implemented in Gradle could also help: gradle/gradle#31908