[DNM] [TEST] fix(config-cache): Defer CLI path resolution to execution phase#1224
[DNM] [TEST] fix(config-cache): Defer CLI path resolution to execution phase#1224runningcode wants to merge 5 commits into
Conversation
The sentry-cli binary path was resolved during Gradle's configuration phase via SentryCliValueSource and cached. When the binary was deleted (OS temp cleanup, build dir cleaned) or the plugin was upgraded (different CLI version), the cached path became stale, causing build failures like "Could not start sentry-cli*.exe". Move CLI path resolution entirely to the execution phase: - Remove SentryCliValueSource, cliExecutableProvider(), and the cliExecutable @input property from all tasks - Resolve the CLI path fresh inside computeCommandLineArgs() at execution time via getSentryCliPath() + maybeExtractFromResources() - Remove SentryCliInfoValueSource and SentryCliVersionValueSource which spawned sentry-cli processes during configuration phase; use BuildConfig.CliVersion and URL-based heuristics instead - Improve maybeExtractFromResources() to handle CLI version changes by extracting the current bundled version when a stale path is detected in build/tmp/ Fixes #613 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
runningcode
requested review from
adinauer,
chromy,
markushi,
rbro112 and
romtsn
as code owners
Instructions and example for changelogPlease add an entry to Example: ## Unreleased
### Features
- Defer CLI path resolution to execution phase ([#1224](https://github.com/getsentry/sentry-android-gradle-plugin/pull/1224))If none of the above apply, you can opt out of this check by adding |
runningcode
changed the title
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 7f9ec0e. Configure here.
| val currentExtractionPath = getCliResourcesExtractionPath(buildDir) | ||
| if (currentExtractionPath.exists()) { | ||
| return currentExtractionPath.absolutePath | ||
| } |
There was a problem hiding this comment.
Silent fallback overrides user-specified CLI path
Low Severity
When getSentryCliPath returns a user-configured path from sentry.properties (cli.executable) that doesn't exist at execution time, maybeExtractFromResources checks currentExtractionPath.exists() before verifying the path origin. If a bundled CLI was previously extracted, this silently returns the bundled CLI path, ignoring the user's explicit configuration. The old code only attempted extraction when cliPath matched the pre-computed extraction path, so a missing user-specified path would propagate as a clear execution error.
Reviewed by Cursor Bugbot for commit 7f9ec0e. Configure here.
Replace private val fields that captured project.projectDir and project.rootDir with abstract DirectoryProperty fields annotated with @internal. Properties are wired during configuration via asSentryCliExec() and resolved during execution, following Gradle best practices for configuration cache compatibility. Also removes duplicate buildDir property from SentryUploadNativeSymbolsTask in favor of the base class property. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace fileValue(project.rootDir) with project.rootProject.layout.projectDirectory so the property is serialized as a project-relative reference by the config cache instead of an absolute path. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The synchronous SentryCliInfoValueSource was removed because it ran sentry-cli during configuration phase, which is incompatible with Gradle's configuration cache. This restores the default organization lookup by running sentry-cli info in a background daemon thread after telemetry is initialized. If the process times out or fails, the scope is left unchanged. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1 participant
Summary
SentryCliValueSource,cliExecutableProvider(), and thecliExecutable@Inputproperty from all tasks — CLI path is now resolved fresh insidecomputeCommandLineArgs()at task execution timeSentryCliInfoValueSourceandSentryCliVersionValueSourcewhich spawnedsentry-cliprocesses during configuration phase; useBuildConfig.CliVersionand URL-based SaaS heuristics insteadmaybeExtractFromResources()to handle CLI version mismatches by extracting the current bundled version when a stale path from a previous plugin version is detectedFixes #613
Fixes GRADLE-70
Root Cause
The CLI path was resolved during configuration via
SentryCliValueSourceand cached by Gradle's configuration cache. This cached path became stale in two scenarios:Version mismatch on plugin upgrade: Config cache stored
sentry-cli-2.46.0.exebut the upgraded plugin shipssentry-cli-2.51.1.exe. The old recovery code inmaybeExtractFromResources()only re-extracted when paths matched exactly, sosentry-cli-2.46.0.exe != sentry-cli-2.51.1.execaused it to skip extraction.Binary deleted: The extracted CLI binary was cleaned up (OS temp cleanup,
./gradlew clean, or daemon restart) while the config cache still held the old path.Approach
Rather than patching the config cache inputs, we eliminate the problem entirely by not caching the CLI path at all. The path is resolved fresh during each task's execution phase, which is the correct time to do filesystem I/O.
This also removes the telemetry
ValueSources that executedsentry-cli infoandsentry-cli --versionduring configuration phase (~38% overhead on large projects per #1100).🤖 Generated with Claude Code