From 7927085475f60c9d4b43880590e265597c31d8b4 Mon Sep 17 00:00:00 2001 From: Daz DeBoer Date: Mon, 7 Sep 2026 17:59:30 -0600 Subject: [PATCH] Update .tool-versions: node 24.18.0, gradle 9.7.1, java 17 (#1068) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The pins in `.tool-versions` had drifted well behind what CI and the Gradle wrappers use. One of them was not just stale but broken. ## node 24.3.0 → 24.18.0 CI runs `node-version: 24`, which resolves to a much newer 24.x. That gap is not harmless: it recently masked a real CI failure outright, because jest 30.5.0's breakage of nock interception reproduces on 24.18.0 but not on 24.3.0. A local run that passes is worth something again. Verified with a clean `./build install` and repeated `./build test` runs on both versions. Both show the same stable core of two failures — the network-dependent wrapper-validation checksum tests — plus an occasional third flake in the same area that varies between runs and between node versions. Nothing attributable to the bump. ## java liberica-11 → liberica-17 This pin was broken. The init-scripts wrapper is on Gradle 9.7.1, which refuses to run a build on JVM 11: ``` Gradle requires JVM 17 or later to run. Your build is currently configured to use JVM 11. ``` So `./build init-scripts` could not have worked with the pinned toolchain. `./gradlew --version` *does* start under JVM 11 and reports successfully, which is likely how the pin survived unnoticed — only an actual build fails. 17 matches what `ci-init-script-check.yml` provisions, so local runs mirror CI. Verified with a clean `./gradlew check` in `sources/test/init-scripts`: BUILD SUCCESSFUL in 3m57s. Java 21 was also tried and passes (3m53s), so moving further later is unblocked. 17 is chosen only to track CI. ## gradle 8.14.2 → 9.7.1 Follows the wrappers, which the workflow samples and init-scripts tests are now on. This matches how the file has been maintained before (e.g. "Use Gradle 8.14 everywhere"). Nothing in `./build` invokes the asdf gradle — every path goes through `./gradlew` — so this only keeps ad-hoc CLI use consistent. ## Notes `ci-check-and-unit-test.yml` still provisions `gradle-version: '8.14.2'` for its unit-test job. That may be equally stale, but it is a CI behaviour change rather than local tooling, so it is left alone here. One flaky run was seen while verifying: two `TestDevelocityInjection` cases against Gradle 6.0.1 failed once, then passed on re-run and on repeat clean builds. Unrelated to these version changes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) --- .tool-versions | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.tool-versions b/.tool-versions index 85a0679a..362c253e 100644 --- a/.tool-versions +++ b/.tool-versions @@ -1,4 +1,4 @@ # Configuration file for asdf version manager -nodejs 24.3.0 -gradle 8.14.2 -java liberica-11.0.26+9 +nodejs 24.18.0 +gradle 9.7.1 +java liberica-17.0.14+10