feat(auto-install): Fail the build on OpenTelemetry version downgrades#268
feat(auto-install): Fail the build on OpenTelemetry version downgrades#268adinauer wants to merge 3 commits into
Conversation
Sentry's sentry-opentelemetry-* artifacts are built and tested against specific OpenTelemetry versions. When another dependency management mechanism (most commonly Spring Boot, via spring-boot-starter-parent or an imported spring-boot-dependencies BOM) forces OpenTelemetry below those versions, it happens silently and can cause ClassNotFoundException / NoSuchMethodError at runtime. Detect this at build time: resolve the OpenTelemetry versions the project's sentry-opentelemetry-* artifacts require and compare them against the versions actually resolved. If any resolved version is a downgrade, fail the build with actionable guidance to import sentry-opentelemetry-bom (noting Maven's first-declaration-wins ordering when Spring Boot is present). Only OpenTelemetry modules that a sentry-opentelemetry-* artifact requires are inspected, so unrelated OpenTelemetry usage is never flagged. The check runs automatically in the lifecycle participant and can be disabled with skipValidateOpenTelemetryVersions. Adds a SENTRY_validateOpenTelemetryVersions telemetry tag. This replaces an earlier approach that auto-installed the BOM: in Maven a late-injected import-scope BOM is a no-op, and rewriting inherited dependencyManagement is too surprising. Mirrors sentry-android-gradle-plugin#1350. Co-Authored-By: Claude <noreply@anthropic.com>
|
| static final @NotNull String SENTRY_OPENTELEMETRY_ARTIFACT_PREFIX = "sentry-opentelemetry-"; | ||
| static final @NotNull String SPRING_BOOT_GROUP_ID = "org.springframework.boot"; | ||
| static final @NotNull String DOCS_URL = | ||
| "https://docs.sentry.io/platforms/java/tracing/instrumentation/opentelemetry/troubleshooting/"; |
There was a problem hiding this comment.
the docs pr actually has /platforms/java/opentelemetry/troubleshooting/ as the path to the troubleshooting guide
The OpenTelemetry version check was nested inside the auto-install guard, so it never ran when skipAutoInstall was enabled. This is wrong — a project that manages its own Sentry dependencies but has a Spring Boot BOM downgrading OpenTelemetry should still get the build-time failure. Move dependency resolution before the auto-install guard so both auto-install and the OTel check can use it. The OTel check now runs independently, gated only by its own skipValidateOpenTelemetryVersions flag. Also remove the sentryVersion parameter from OpenTelemetryVersionChecker .check() — it now derives the version from the resolved sentry-opentelemetry-* artifact since it was only used in the error message. Co-Authored-By: Claude <noreply@anthropic.com>
Fix the docs URL to match the actual path in the docs PR: /platforms/java/opentelemetry/troubleshooting/ Expand the changelog entry to explain the check, that it runs independently of auto-install, and how to disable it. Co-Authored-By: Claude <noreply@anthropic.com>
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.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit eb9fb16. Configure here.
| try { | ||
| resolvedArtifacts = resolver.resolveArtifactsForProject(project, session); | ||
| } catch (DependencyResolutionException e) { | ||
| logger.error("Unable to resolve all dependencies", e); |
There was a problem hiding this comment.
Resolves when both checks skipped
Medium Severity
afterProjectsRead always calls resolveArtifactsForProject before consulting isSkipAutoInstall() or isSkipValidateOpenTelemetryVersions(). Previously, when auto-install was skipped (including via global skip or no Sentry plugin), dependency resolution in this participant did not run at all.
Reviewed by Cursor Bugbot for commit eb9fb16. Configure here.


Builds on top of #265. Maven port of getsentry/sentry-android-gradle-plugin#1350 (which itself is stacked on the SAGP equivalent of #265, getsentry/sentry-android-gradle-plugin#1349).
What
Fails the build when the OpenTelemetry versions resolved for a project are downgraded below what Sentry's
sentry-opentelemetry-*artifacts were built and tested against.Why
Sentry's OpenTelemetry artifacts declare the exact OpenTelemetry versions they require. When another dependency management mechanism — most commonly Spring Boot (via
spring-boot-starter-parentor an importedspring-boot-dependenciesBOM) — forces OpenTelemetry below those versions, it happens silently (the user never declares an OTel version). Running against the mismatched versions can throwClassNotFoundException/NoSuchMethodErrorat runtime. This surfaces the problem at build time with actionable guidance instead.This replaces an earlier approach that auto-installed the BOM (previous PR #266). In Maven a late-injected import-scope BOM is a no-op (BOM imports are flattened during effective-model building, before
afterProjectsRead), and rewriting inheriteddependencyManagementin place is too surprising. Detecting-and-failing is the more honest behavior — same conclusion as SAGP #1350.How it works
sentry-opentelemetry-*artifact.sentry-opentelemetry-*artifact to determine the OpenTelemetry versions it requires (declared dependencies + its own dependency management), then compares against the versions actually resolved on the project. A resolved version lower than the required version is a downgrade.sentry-opentelemetry-*artifact requires are inspected, so unrelated OpenTelemetry usage is never flagged. Unparseable versions are skipped.<dependencyManagement>import forsentry-opentelemetry-bomat the resolved Sentry version, noting Maven's first-declaration-wins ordering when Spring Boot is present.Config
Opt out with
<skipValidateOpenTelemetryVersions>true</skipValidateOpenTelemetryVersions>. Adds aSENTRY_validateOpenTelemetryVersionstelemetry tag.Phase / placement
Implemented in the lifecycle participant (runs before any phase, automatically) rather than as an opt-in
validate-phase mojo, so users get protected by default — matching SAGP #1350's automatic, default-on behavior.Open items (mirroring SAGP #1350)
.../platforms/java/tracing/instrumentation/opentelemetry/troubleshooting/) and must resolve to a live page before release.Tests
OpenTelemetryVersionCheckerTest): downgrade detection (match / upgrade / not-resolved / alpha / unparseable), eligibility gate, and failure-message content (mismatch line, BOM snippet, opt-out, Spring Boot ordering note).OpenTelemetryVersionCheckTestIT): build fails on a Spring Boot parent downgrade with the guidance message; succeeds when not downgraded; succeeds when disabled; no-op without a Sentry OpenTelemetry dependency.Co-authored with Claude.