Spring Boot 4 CI matrix never tested against Spring Boot 4 (profile "spring-boot-4" not activated)

[megglos]

Description

The CI "Spring Boot 4" test matrix jobs have never actually tested against Spring Boot 4. They silently fall back to the default Spring Boot version (currently 3.5.14).

During the 8.8.26 release, the deploy run surfaced the warning:

[WARNING] The requested profile "spring-boot-4" could not be activated because it does not exist.

(seen in run 27198516460 / job 80303227656)

Root cause

The matrix in .github/workflows/build-test.yml declares the Spring Boot versions unquoted:

spring-boot-version: [ 3.5, 4.0]

YAML parses the unquoted 4.0 as a float, and GitHub Actions renders that float as 4 (the trailing-zero fraction is dropped). The Maven invocation:

-P !localBuild,spring-boot-${{ matrix.spring-boot-version }}

therefore expands to -P !localBuild,spring-boot-4, but the Maven profile is named spring-boot-4.0 (spring-test/pom.xml):

<profile>
  <id>spring-boot-4.0</id>
  <properties>
    <dependency.spring-boot.version>4.0.1</dependency.spring-boot.version>
  </properties>
</profile>

Maven can't find spring-boot-4, emits the warning, and the activation is a no-op — so dependency.spring-boot.version stays at the default 3.5.14 and the tests run against Spring Boot 3.5, not 4.

Evidence:

• The job is named "Run tests on ubuntu-latest and Spring-Boot 4" (note 4, not 4.0) — confirming the matrix value rendered as 4.
• The logged command shows -P !localBuild,spring-boot-4.
• Two could not be activated warnings appear in the job log.

The 3.5 entry is unaffected: it is an intentional placeholder for the default version (there is no spring-boot-3.5 profile by design), and a float with a non-zero fraction renders unchanged.

Expected behaviour

The "Spring Boot 4" matrix jobs should activate the spring-boot-4.0 profile and genuinely resolve/test against Spring Boot 4.0.1, with no "could not be activated" warning.

Affected

This was introduced in #2007 (profile + workflow added together). The defect is present on at least:

• main
• stable/8.8

Both define the spring-boot-4.0 profile and use the unquoted 4.0 matrix value, so both are affected. Other active stable branches with the same setup should be checked too.

Proposed fix

Quote the matrix values so YAML keeps them as strings:

spring-boot-version: [ '3.5', '4.0' ]

(both occurrences — the unit-test matrix and the testcontainers matrix). This makes ${{ matrix.spring-boot-version }} expand to 4.0, matching the spring-boot-4.0 profile id.

Alternatively, rename the profile to spring-boot-4 to match the coerced value — but quoting the matrix is the more robust fix and keeps the profile id semantically versioned.

Verification

After the fix, the "Spring Boot 4" jobs should:

• run -P !localBuild,spring-boot-4.0,
• show no "could not be activated" warning,
• and resolve spring-boot-dependencies:4.0.1 (verifiable via mvn dependency:tree / the effective Spring Boot version in the build).

Environment

• Component: zeebe-process-test CI (.github/workflows/build-test.yml) + spring-test/pom.xml
• Affected versions: main (8.8.27-SNAPSHOT), stable/8.8

[megglos]

Branch-by-branch assessment (correction to the "Affected" section above)

I checked all active branches. The earlier note that main is affected was incorrect — main and stable/8.9 have no Spring Boot version matrix at all and already default to Spring Boot 4. Only stable/8.8 is actually broken.

Branch	SB version matrix	spring-test/pom.xml profile	Default SB	Effective result	Fix needed?
main	none	none	4.0.6	builds against SB4 by default	No — SB4 already covered
stable/8.9	none	none	4.0.6	builds against SB4 by default	No — SB4 already covered
stable/8.8	[ 3.5, 4.0] / [ default, 4.0 ]	spring-boot-4.0 (4.0.1)	3.5.14	4.0 → YAML float → 4 → -P spring-boot-4 (no such profile) → falls back to default 3.5.14. SB4 never tested.	YES — broken
stable/8.7	[ default, 3.5] ×2	spring-boot-3.5 (3.5.7)	3.4.5	3.5 → 3.5 (non-zero fraction preserved) → -P spring-boot-3.5 activates correctly	No (works)
stable/8.6	[ default, 3.5] ×2	spring-boot-3.5 (3.5.7)	3.4.5	3.5 → 3.5 → activates correctly	No (works)

Why only 4.0 breaks

The YAML float-coercion only drops the fraction when it's a trailing zero: 4.0 → 4, but 3.5 → 3.5. That's why stable/8.7/stable/8.6 (which use 3.5) are fine, while stable/8.8 (which uses 4.0) is broken.

Confirmation:

• stable/8.8 job is named "Spring-Boot 4" and logs -P !localBuild,spring-boot-4 + two could not be activated warnings.
• stable/8.7 job is named "Spring-Boot 3.5" (value preserved) with no warning — verified on run 27042128933.

Fix scope

• stable/8.8 — required fix: quote the matrix values so YAML keeps them strings:

  spring-boot-version: [ '3.5', '4.0' ]      # unit-test matrix
  spring-boot-version: [ default, '4.0' ]    # testcontainers matrix

  Note: once the spring-boot-4.0 profile actually activates, the SB4 jobs may surface real Spring Boot 4 compatibility failures that have been masked until now.
• stable/8.7 / stable/8.6 — not broken; quoting '3.5' is optional hygiene to prevent the same trap if the version is ever bumped to an X.0.
• main / stable/8.9 — no change needed.

---

Update — Spring Boot 4 coverage added to stable/8.7 (#2308). The float-coercion bug above did not affect stable/8.7, but this assessment missed a separate gap: stable/8.7 had no Spring Boot 4 CI coverage at all — its matrix tested only the default version and 3.5, and it had no spring-boot-4.0 profile. Since Spring Boot 4 was part of the support initiative (camunda/camunda#41279), #2308 adds it, mirroring #2307 — but using 8.7's Spring Boot 3 SDK artifact name spring-boot-starter-camunda-sdk (8.8 uses camunda-spring-boot-starter). Verified locally: the embedded suite passes under -P spring-boot-4.0 with camunda-spring-boot-4-starter:8.7.30 + JUnit 6.0.1.

stable/8.6 remains unchanged (not part of the Spring Boot 4 initiative).

[megglos]

Resolved — Spring Boot 4 now genuinely tested and passing on stable/8.8

Fix in PR #2307. Once the matrix was quoted so the spring-boot-4.0 profile actually activated, two previously-masked SB4 incompatibilities surfaced and were fixed:

1. JUnit 5 → 6. The root pom imports junit-bom (5.13.4) before spring-boot-dependencies, so its version wins. Spring Boot 4 / Spring Framework 7 require JUnit 6 (SpringExtension calls ExtensionContext.Store.computeIfAbsent(...), absent in JUnit 5 → NoSuchMethodError). Aligned dependency.junit.version → 6.0.1 (the version spring-boot-dependencies:4.0.1 manages) under the profile.
2. SB3-only Camunda starter. camunda-spring-boot-starter targets Spring Boot 3; under SB4 its CamundaActuatorConfiguration.micrometerMetricsRecorder fails with @ConditionalOnMissingBean ... BeanTypeDeductionException. The SDK publishes a dedicated camunda-spring-boot-4-starter (for 8.8.x); it's selected via a camunda.spring-boot.starter.artifactId property the profile overrides. Default build is unchanged.

CI result on the PR: all Spring-Boot 4.0 jobs green (ubuntu/macos/windows unit + ubuntu testcontainers), and job names now correctly render 4.0 instead of 4.

Branch scope (no other branches need this)

• main / stable/8.9 — already default to Spring Boot 4.0.6; their 8.9.x SDK is SB4-native (uses the regular starter). No change.
• stable/8.7 / stable/8.6 — use 3.5, which YAML preserves; the matching spring-boot-3.5 profile activates correctly. No change.
• The camunda-spring-boot-4-starter swap is specific to the 8.8 SDK line and must not be backported.