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 2 commits into
no/drop-boot-2.4-2.6from
no/spring-boot-matrix-tasks
Draft

runningcode wants to merge 2 commits 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 of its Spring Boot line in gradle/spring-boot-versions.json, 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 still runs one job per version, but a small first job now builds the matrix from gradle/spring-boot-versions.json. Each job runs its version's aggregate in the Boot module and its WAR module by project path, e.g. ./gradlew :sentry-spring-jakarta:allIntegrationTestsBoot3_2_12 :sentry-spring-boot-jakarta:allIntegrationTestsBoot3_2_12. The check names are the same as on main.
  • One version list: the versions live only in gradle/spring-boot-versions.json, which build-logic and the workflows both read. 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.

Why still one job per version: this PR first ran each line in a single job, which doubled the wall time (Boot 3 took 12.5 minutes instead of about 6). One runner ran every version's suites, and the bare task name made Gradle configure every project.

💡 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.

📝 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

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.62.0 (1) release

⚙️ sentry-android Build Distribution Settings

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>
@runningcode
runningcode force-pushed the no/spring-boot-matrix-tasks branch from 033bff7 to 8d9fab1 Compare October 27, 2026 14:33
One job per Boot line doubled the matrix wall time, e.g. 12.5 minutes
instead of about 6 for Boot 3. A single runner ran every version's suites,
and the bare task name made Gradle configure every project to find it.

The versions move to gradle/spring-boot-versions.json. build-logic reads
it, and each workflow turns its line into one job per version, which runs
that version's aggregate in both modules by project path. The version list
stays in one place, and the check names match main's again.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

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