Skip to content

test(spring): [Sample Tests 42] Run each Spring Boot matrix version as its own Gradle task - #6382

Draft
runningcode wants to merge 1 commit into
no/drop-boot-2.4-2.6from
no/spring-boot-matrix-tasks
Draft

runningcode wants to merge 1 commit into
no/drop-boot-2.4-2.6from
no/spring-boot-matrix-tasks

Conversation

@runningcode

@runningcode runningcode commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

PR Stack (Sample Tests)


📜 Description

Replaces the perl edit of gradle/libs.versions.toml in the Spring Boot matrix workflows with a Gradle task per suite and Spring Boot version.

  • New io.sentry.spring-boot-matrix plugin in build-logic. A module lists its suites in a springBootMatrix block, and the plugin registers <suite>Boot<version> for each version in SpringBootVersions, e.g. integrationTestWebfluxBoot3_2_12.
  • How a version is swapped in: the task reuses the suite's compiled classes on a runtime classpath resolved for that version. That classpath extends the suite's implementation and runtimeOnly and swaps every org.springframework.boot artifact, the BOM included, to the version. That's what the catalog edit did.
  • The OpenTelemetry agent suites pass the fixture app's classpath for the same version to runAgentFixture, in both init modes.
  • Aggregates: allIntegrationTestsBoot3_2_12 runs one version's suites in a module, and allIntegrationTestsBoot3 runs every version's.
  • CI: each workflow is one job per Boot line, running ./gradlew allIntegrationTestsBoot<N> --continue from the root. That picks up both the Boot module and its WAR module. --continue keeps a failing version from hiding the others.
  • One version list: the versions live only in SpringBootVersions. The WAR suites in sentry-spring{,-jakarta,-7} use their Boot module's list.
  • e2e_tests.mdc now describes the tasks.

What changes: the SDK and the suites compile once, against the catalog's version, and only the runtime classpath varies. That's how users run our published jars, and it can catch binary incompatibilities that recompiling hid. Suite code may only use APIs that exist in the oldest version of its line. The next PR brings back a check that the SDK's main code compiles against that version.

CI trade-off: there's one check per Boot line instead of one per version, and each job takes longer. In exchange, everything compiles once and there's a single version list. A failing version shows up in the test report.

💡 Motivation and Context

Closes #6379 (JAVA-802). A version could only be tested locally by editing the catalog by hand, and every matrix job recompiled the SDK and the suites. Now it's ./gradlew :sentry-spring-boot-jakarta:allIntegrationTestsBoot3_2_12.

💚 How did you test it?

  • Every classpath I compared matches the perl edit's exactly, with the same modules and versions:
    • Boot 3 integrationTest at 3.2.12;
    • sentry-spring and the Boot 2 integrationTestOtelNoAgent at 2.7.0;
    • sentry-spring-7 and the Boot 4 integrationTestOtlp at 4.0.0.
  • All three lines pass locally: 28 Boot 3 tasks, and 37 Boot 2 and Boot 4 tasks. The test logs show each one on its own Spring Boot and Spring Framework version.
  • Locally, the Boot 3 line took 3m31s, and the Boot 2 and 4 lines together took 3m48s. The CI time for one job per line will show on this PR's first run.

📝 Checklist

  • I added GH Issue ID & Linear ID
  • I added tests to verify the changes.
  • No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
  • I updated the docs if needed.
  • I updated the wizard if needed.
  • Review from the native team if needed.
  • No breaking change or entry added to the changelog.
  • No breaking change for hybrid SDKs or communicated to hybrid SDKs.
  • Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

#6383 compiles the SDK against each line's oldest version.

#skip-changelog

🤖 Generated with Claude Code

The Spring Boot matrix workflows tested each version by rewriting the
catalog with perl, so a version could only be tested locally by editing
the catalog, and every job recompiled the SDK and the suites.

The new io.sentry.spring-boot-matrix plugin registers a test task per
suite and version, e.g. integrationTestWebfluxBoot3_2_12. It reuses the
suite's compiled classes on a runtime classpath resolved for that
version, which swaps every org.springframework.boot artifact, the BOM
included, as the catalog edit did. The resolved classpaths match the
catalog edit's exactly.

So the SDK and the suites now compile once, against the catalog's
version, and only the runtime varies, which is how users run our jars.
Suite code may only use APIs of the oldest version of its line.

allIntegrationTestsBoot<version> runs one version's suites in a module,
and allIntegrationTestsBoot<major> every version's. Each workflow runs
the latter from the root in one job per Boot line, with --continue so a
failing version doesn't hide the others. The versions live only in
SpringBootVersions in build-logic.

Resolves JAVA-802

Co-Authored-By: Claude <noreply@anthropic.com>
This was referenced Oct 26, 2026
@sentry

sentry Bot commented Oct 26, 2026

Copy link
Copy Markdown

📲 Install Builds

Android

🔗 App Name App ID Version Configuration
SDK Size io.sentry.tests.size 8.61.1 (1) release

⚙️ sentry-android Build Distribution Settings

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant