update-packages.yml hardcodes JDK 21 with no caller override, breaking Gradle callers pinned to a different toolchain #138

What's wrong

The reusable update-packages.yml workflow hardcodes JAVA_VERSION: "21" for its "Setup Java" step, with no caller-facing way to pin a different JDK version. This has made Update Packages fail on every run in Cratis/Arc.Kotlin since 2026-09-17 (run history) — 15+ consecutive failures, including the most recent run: https://github.com/Cratis/Arc.Kotlin/actions/runs/36858216258.

Root cause (verified, not a dependency regression)

Arc.Kotlin's Gradle build requires exactly JDK 17 project-wide (jvmToolchain(17) in the root build.gradle.kts), and since 2026-09-16 a native KSP feature ("shared fluent validation") hard-asserts this at runtime:

require(version == "2.4.20" && Runtime.version().feature() == 17) {
    "shared fluent extraction requires kotlin-compiler-embeddable 2.4.20 and JDK17 (found $version / ${Runtime.version()})"
}

Every one of Arc.Kotlin's own workflows (build.yml, codeql.yml, publish.yml, proxy-contract-ci.yml, chronicle-real-kernel.yml, mongo-replicaset.yml, client-snippets.yml) sets up java-version: "17" and has stayed green through and after that merge. Only update-packages.yml — which always sets up Java 21 via this reusable workflow, with no way for the caller to override — fails, at the "Build Gradle" step, with:

e: [ksp] .../FluentContracts.kt:12: [ARCKSP0310] Fluent validator '...': parser dependency unavailable
or unsupported (shared fluent extraction requires kotlin-compiler-embeddable 2.4.20 and JDK17
(found 2.4.20 / 21.0.12.1+1-LTS)); use arc-ksp with kotlin-compiler-embeddable 2.4.20 on JDK17.

I reproduced this locally: with only JDK 21 available, ./gradlew build --no-daemon fails with the exact same ARCKSP0310 error in ContractTests and the Kotlin SpringBoot sample. With a JDK 17 installation also registered (toolchain), the same build (including the actual package bump this workflow would make — jacksonVersion 3.2.2 → 3.2.3, which is itself harmless and compiles/tests clean) succeeds end to end.

(Note: I couldn't inspect the actual failing run logs directly — gh api .../actions/jobs/<id>/logs and gh run view --log-failed both return 410 Gone for every run in this workflow's history, even ones from the last 24h. I had to reproduce the failure locally instead.)

Suggested fix

Give callers a way to pin the JDK version used for the Gradle ecosystem, the same way update-packages.yml already lets .NET callers pin their SDK via global.json (see the "Honor caller SDK pins during package updates" change). Options, roughly in order of preference:

1. Read the caller's own Gradle toolchain requirement (e.g. via a quick ./gradlew properties / a generated JavaLanguageVersion probe, or a repo-local pin file) the same way global-json-file is honored for .NET, so no caller-side input is needed at all.
2. Failing that, add an explicit java-version input (default "21", to stay backward compatible) that callers can set, and have Arc.Kotlin's .github/workflows/update-packages.yml pass java-version: "17".

Either way, please don't make this Arc.Kotlin-specific — other Gradle/Kotlin repos with a toolchain pin different from the workflow's default will hit the same wall.

Impact

Arc.Kotlin's dependency updates have not been able to self-validate and publish since 2026-09-17. No action is needed on Arc.Kotlin's side until this is fixed upstream — its own build and CI are healthy.

Status

State: Done — Merged in #209; closed manually (Workflows publishes no releases)
Branch: stage-422-atomic-execution (#209)
Scope: java-version input (default 21) for update-packages.yml; shipped with #153 in one patch PR
Delivered: Nothing yet.
Remaining: To be confirmed.
Follow-ups: None.