chore(deps): update Gradle to v9.4.1#5063
Conversation
c8f0c9b to
fcb54c7
Compare
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. Internal Changes 🔧Deps
🤖 This preview updates automatically when you update the PR. |
d554059 to
2b5f299
Compare
2b5f299 to
917cb88
Compare
eb08e70 to
be8d422
Compare
3269f42 to
705f4e7
Compare
a3ae321 to
85f3890
Compare
📲 Install BuildsAndroid
|
|
|
||
| object Config { | ||
| val AGP = System.getenv("VERSION_AGP") ?: "8.6.0" | ||
| val AGP = System.getenv("VERSION_AGP") ?: "8.13.1" |
There was a problem hiding this comment.
AGP 8.13.1 incompatible with Gradle 9.4.1
High Severity
The default AGP version was bumped to 8.13.1, but AGP 8.x is only supported with Gradle 8.x. With the Gradle wrapper now at 9.4.1, the Android build modules will fail because AGP 8.13.x requires Gradle 8.13 and is not compatible with Gradle 9. Only AGP 9.x (e.g., 9.0.x or 9.1.x) is supported with Gradle 9.x. The same applies to the android.experimental.lint.version=8.13.1 in gradle.properties.
Additional Locations (1)
Performance metrics 🚀
|
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| 319f256 | 317.53 ms | 370.83 ms | 53.29 ms |
| 62b579c | 318.48 ms | 367.71 ms | 49.24 ms |
| bbc35bb | 298.53 ms | 372.17 ms | 73.64 ms |
| abfcc92 | 309.54 ms | 380.32 ms | 70.78 ms |
| 0eaac1e | 316.82 ms | 357.34 ms | 40.52 ms |
| d15471f | 304.55 ms | 408.43 ms | 103.87 ms |
| f064536 | 349.86 ms | 417.66 ms | 67.80 ms |
| 22f4345 | 312.78 ms | 347.40 ms | 34.62 ms |
| d364ace | 382.77 ms | 443.21 ms | 60.44 ms |
| b8bd880 | 314.56 ms | 336.50 ms | 21.94 ms |
App size
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| 319f256 | 1.58 MiB | 2.19 MiB | 619.79 KiB |
| 62b579c | 0 B | 0 B | 0 B |
| bbc35bb | 1.58 MiB | 2.12 MiB | 553.01 KiB |
| abfcc92 | 1.58 MiB | 2.13 MiB | 557.31 KiB |
| 0eaac1e | 1.58 MiB | 2.19 MiB | 619.17 KiB |
| d15471f | 1.58 MiB | 2.13 MiB | 559.54 KiB |
| f064536 | 1.58 MiB | 2.20 MiB | 633.90 KiB |
| 22f4345 | 1.58 MiB | 2.29 MiB | 719.83 KiB |
| d364ace | 1.58 MiB | 2.11 MiB | 539.75 KiB |
| b8bd880 | 1.58 MiB | 2.29 MiB | 722.92 KiB |
…lity (#5263) * fix(build): remove Spring Boot 2 Gradle plugin for Gradle 9 compatibility The Spring Boot 2.7.x Gradle plugin uses removed Gradle APIs (LenientConfiguration.getFiles()) that are incompatible with Gradle 9. Library modules (sentry-spring, sentry-spring-boot, sentry-spring-boot-starter): - Replace SpringBootPlugin.BOM_COORDINATES with direct BOM reference via version catalog (libs.springboot2.bom) - Remove the 'apply false' plugin declaration entirely Sample apps (spring-boot, webflux, otel, netflix-dgs): - Replace Spring Boot plugin with Shadow plugin for fat JAR creation - Add application plugin for main class configuration - Use platform(libs.springboot2.bom) for dependency version management - Configure shadow JAR to merge Spring metadata files - Replace BootRun task with JavaExec in otel sample * fix: set duplicatesStrategy=INCLUDE for shadow JAR spring.factories merge Shadow plugin 9.x defaults to DuplicatesStrategy.EXCLUDE, which drops duplicate META-INF/spring.factories entries before transformers can merge them. Setting INCLUDE allows the AppendingTransformer to see all entries and properly concatenate spring.factories from all JARs. Without this, the shadow JAR only contains spring.factories from a single dependency, causing Spring Boot auto-configuration to fail (e.g. missing RestTemplateBuilder, no embedded web server). * fix: remove duplicate shadow plugin entry in version catalog * Format code * fix: update system test runner for shadow JAR compatibility - Auto-detect shadowJar vs bootJar build task based on build.gradle.kts - Add fallback HTTP readiness check for shadow JAR apps that lack actuator endpoints (actuator web endpoints don't work in flat JARs) - Append spring-autoconfigure-metadata.properties in shadow JAR config * fix(otel): use DuplicatesStrategy.INCLUDE for otel agent shadow JAR Shadow 9.x enforces duplicatesStrategy before transformers run, so DuplicatesStrategy.FAIL prevents mergeServiceFiles from merging inst/META-INF/services/ files that exist in both the upstream OTel agent JAR and the isolated distro libs. Switching to INCLUDE lets the transformer see all duplicates and merge them correctly. * Exclude test-support modules from api validation * Verbose system test output and wire inputs for them properly * align coroutines version to 1.9.0 for system tests * fix(otel): use mergeServiceFiles path instead of include for Shadow 9.x Shadow 9.x's ServiceFileTransformer strips the `inst/` prefix when using `include("inst/META-INF/services/*")`, placing merged service files under `META-INF/services/` instead of `inst/META-INF/services/`. This breaks the OTel agent's classloader which expects isolated services under `inst/`. Using `path = "inst/META-INF/services"` preserves the correct output path. Also add missing `duplicatesStrategy = DuplicatesStrategy.INCLUDE` to console-otlp, log4j2, and console-opentelemetry-noagent shadow JARs so that mergeServiceFiles and Log4j2 transformers can see duplicates before they are deduplicated. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(otel): add default mergeServiceFiles for bootstrap service relocation Shadow 9.x only applies package relocations to service files that are claimed by a ServiceFileTransformer. The ContextStorageProvider service file at META-INF/services/ was not being relocated because it wasn't handled by any transformer — only the inst/META-INF/services/ files were. Adding a default mergeServiceFiles() call ensures bootstrap service files (like ContextStorageProvider) go through the transformer and get properly relocated to their shaded paths. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(spring-boot2): pre-merge Spring metadata for Shadow 9.x compatibility Shadow 9.x enforces DuplicatesStrategy before transformers run, which breaks the `append` transformer for spring.factories and other Spring metadata files. Only the last copy survives instead of being concatenated. Replace `append` calls with a pre-merge task that manually concatenates Spring metadata files (spring.factories, spring.handlers, spring.schemas, spring-autoconfigure-metadata.properties) from the runtime classpath before the shadow JAR is built. The merged files are included first in the shadow JAR so they take precedence over duplicates from dependency JARs. This fixes the PersonSystemTest failure where @SentrySpan AOP and JDBC instrumentation weren't working because SentryAutoConfiguration wasn't properly registered in the merged spring.factories. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Format code * fix(lint): suppress OldTargetApi for uitest-android module Lint 8.13.1 (set via android.experimental.lint.version) expects targetSdk 37 but we target 36. This is a test-only module so suppressing is safe. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(spring-boot2): make mergeSpringMetadata configuration-cache compatible Resolve the runtime classpath at configuration time (not inside doLast) so the task doesn't capture Gradle script object references that can't be serialized by the configuration cache. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * formatting * fix(spring-boot2): replace from() with doLast JAR patching for spring metadata The from() approach with DuplicatesStrategy.INCLUDE doesn't work because dependency JARs' spring.factories overwrites the pre-merged version. Instead, let the shadow JAR build normally, then use a doLast action to replace the Spring metadata files in the built JAR with the properly merged versions using the NIO ZIP filesystem API. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * formatting * fix(spring-boot2): merge AutoConfiguration.imports + doLast JAR patching The shadow JAR was missing the embedded web server auto-configuration because AutoConfiguration.imports (used by SB 2.7+) had duplicate entries from multiple dependency JARs, with only the last copy surviving. Add AutoConfiguration.imports to the pre-merge file list and use doLast JAR patching via NIO ZIP filesystem to replace metadata files after the shadow JAR is built, avoiding the DuplicatesStrategy issue entirely. Also suppress OldTargetApi lint for uitest-android-benchmark module. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(spring-boot2): also merge ManagementContextConfiguration.imports This file has duplicate entries across actuator JARs and needs the same pre-merge treatment as AutoConfiguration.imports. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * formatting * fix(spring-boot2): use separate patchSpringMetadata task for JAR patching The doLast on shadowJar doesn't run when the task is cached/up-to-date. Move JAR patching to a separate `patchSpringMetadata` task that is finalized by shadowJar, ensuring it always runs. Also use recursive walkTopDown to handle nested directories (e.g. META-INF/spring/). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * formatting * fix(spring-boot2): revert to doLast on shadowJar for Spring metadata patching The separate patchSpringMetadata task approach caused regressions — the finalizedBy relationship didn't reliably execute the patching in CI. Revert to doLast directly on shadowJar with outputs.upToDateWhen { false } to ensure the patching always runs. Also use walkTopDown for recursive directory traversal (needed for META-INF/spring/ subdirectory). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * formatting * fix(spring-boot2): inline Spring metadata merge into shadowJar doLast Replace the separate mergeSpringMetadata task with inline doLast on shadowJar that resolves runtimeClasspath at execution time (not configuration time). This ensures all project dependency JARs are built before their spring.factories entries are read and merged. Verified locally: 20/21 system tests pass. Only PersonSystemTest 'create person works' fails due to @SentrySpan AOP limitation in shadow JARs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * formatting * fix(build): make Spring sample shadowJar patching config-cache safe * fix(build): merge Spring metadata properties in shadow jars * fix(build): preserve escaped spring metadata keys * refactor(samples): drop no-op spring shadow service merging * test(android): Avoid ANR profiling integration test race Drive the ANR profiling state-machine test synchronously instead of starting the background polling thread. The previous version could read the queue-backed profile store while the polling thread was still appending stack traces, which made the release unit test flaky with NoSuchElementException in QueueFile iteration. Co-Authored-By: Codex <noreply@openai.com> * fix(test): Require actuator health for Spring readiness * ref(build): Share Spring metadata file list Move the Spring metadata entry list into MergeSpringMetadataAction so the Spring sample shadowJar tasks use one source of truth. Drop the temporary system-test-runner unit test and keep verification on the existing Spring Boot system test flow. Co-Authored-By: Codex <noreply@openai.com> * docs(build): Document Spring metadata merge action Explain that MergeSpringMetadataAction patches shadow JARs by merging Spring metadata with file-specific semantics and by preserving service-provider registrations from the runtime classpath. This keeps the intent of the build logic clear without changing behavior. Co-Authored-By: Codex <noreply@openai.com> * build(opentelemetry): Fail agent shadow duplicates by default Set the final agent shadowJar to fail on unexpected duplicate entries while still allowing service descriptors to merge in the bootstrap and inst paths. This keeps duplicate handling strict without breaking the service file transformers Shadow still relies on. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Sentry Github Bot <bot+github-bot@sentry.io> Co-authored-by: Roman Zavarnitsyn <rom4ek93@gmail.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Codex <noreply@openai.com>
| alias(libs.plugins.errorprone) | ||
| alias(libs.plugins.gradle.versions) | ||
| id("com.apollographql.apollo3") version "3.8.2" | ||
| id("com.apollographql.apollo") version "4.1.1" |
There was a problem hiding this comment.
Bug: The sentry-system-test-support module was upgraded to Apollo 4, but sample projects using its TestHelper class still depend on Apollo 3, causing runtime class resolution failures during tests.
Severity: HIGH
Suggested Fix
To resolve this, either upgrade all sample projects that use TestHelper to also use Apollo 4 dependencies, or revert the Apollo version upgrade in sentry-system-test-support to maintain compatibility with the existing sample projects that rely on Apollo 3.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: sentry-system-test-support/build.gradle.kts#L8
Potential issue: The `sentry-system-test-support` module was upgraded to use Apollo 4,
but the sample projects that depend on it were not. These sample projects use the
`TestHelper` class from the support module, which now exposes and uses types from Apollo
4 (e.g., `com.apollographql.apollo.ApolloClient`). However, the sample projects only
have Apollo 3 on their test classpath. When tests in these sample projects are executed,
they will fail with runtime errors like `ClassNotFoundException` because the required
Apollo 4 classes are not available.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
There are 3 total unresolved issues (including 2 from previous reviews).
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit d1e5025. Configure here.
| MergeSpringMetadataAction.DEFAULT_SPRING_METADATA_FILES, | ||
| ) | ||
| ) | ||
| } |
There was a problem hiding this comment.
Missing mergeServiceFiles in Spring Boot shadow builds
Medium Severity
The Spring Boot 2 samples converted from the Spring Boot plugin to Shadow plugin lack mergeServiceFiles() in their shadowJar configuration. The MergeSpringMetadataAction runs in doLast to patch the JAR afterward, but if Shadow 9.x's duplicate handling causes a build failure before doLast executes (due to duplicate META-INF/services/ or Spring metadata entries), the patching never runs. Other Shadow samples in this PR (e.g., console-otlp) explicitly set duplicatesStrategy = DuplicatesStrategy.INCLUDE and call mergeServiceFiles(), but these Spring Boot samples do neither.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit d1e5025. Configure here.


Bumps scripts/update-gradle.sh from v8.14.3 to v9.4.1.
Auto-generated by a dependency updater.
Changelog
Commits between v8.14.3 and v9.4.1
services.gradle.orgfallback if sources cannot be found (#36839)ProjectBuilderbehavior changes in upgrade guide (#36826)ProjectBuilderbehavior changes in upgrade guideInjectedfrom constructorBuildModeltypes from DCL type discovery if only used in supertypesdeclarative-dsl-internal-utilsArtifactRepositoryContainer, as hiddenHiddenInDefinitionAvailableJavaHomescauses NPEs when environment is not ready gradle/gradle#35766gradle.properties(#34712)ConfigurationCacheMultiEntriesPerKeyIntegrationTestgradle.propertiesdeletionEnvironment#propertiesFilemethodgradle.propertiesgradle.propertiesto separate classgradle.propertiesConfigurationCacheFingerprintWriterkotlin-dslhelper function is used in multiple layers of precompiled script plugins (#36187)ignoreDuplicateProblemCountwithenforceTotalProblemCounttotalProblemCounttotalProblemCounttotalProblemsCounttotalProblemsCountLocationListInstallationSupplierDefaultJvmToolchainsConfigurationValidatorToolchianBuildOptionsreleaseDefaultIvyPatternMatcherExcludeRuleSpec#toStringresilient to nullsexecuter.withStackTraceChecksDisabled()callsPersistentMap#modifywhen there are partial hash collisions (#36224)PersistentMap#modifywhen there are partial hash collisionsNormalizingExcludeFactoryDefaultCompositeExcludeTestDefaultExcludeFactoryNormalizingExcludeFactoryNodeStaterestorefor raw setters meant only for CC deserializationDeclarativeDslConfigurationPerformanceTestas it needs new contract in the baseline"LazySortedReferenceHashSet.sort()for thread-safe reading (#36128)sortfor thread-safe readingcollections(#36115)ProjectFeatureDefinitionAbstractClassBuilderDeclarativeDslConfigurationPerformanceTestas it needs new contract in the baselineNestedfor the nested model inDeclarativeDslTestProjectGenerator