Daz DeBoerandClaude Opus 5 7927085475 Update .tool-versions: node 24.18.0, gradle 9.7.1, java 17 (#1068)
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) <noreply@anthropic.com>
2026-09-07 17:59:30 -06:00
2026-09-07 16:58:55 -06:00
2026-09-07 22:59:44 +00:00
2026-09-07 16:58:55 -06:00
2026-06-10 08:54:56 -06:00
2019-09-21 20:57:04 +02:00
2026-04-03 15:25:10 -06:00

GitHub Actions for Gradle builds

This repository contains a set of GitHub Actions that are useful for building Gradle projects on GitHub.

Note

Choice of caching providers in v6

To provide the fastest possible build experience this action includes Enhanced Caching via gradle-actions-caching, an optimized provider powered by proprietary technology. This feature is free for all public repositories and is currently available as a Free Preview for private repositories.

Prefer a 100% Open Source (MIT) path? We also provide a Basic Caching provider as a thin wrapper over actions/cache. This provider is free for all repositories (public and private) and can be enabled at any time by setting cache-provider: basic.

For a full breakdown of the components, usage tiers, and our Safe Harbor data privacy commitment, see our Distribution & Licensing Guide.

The setup-gradle action

The setup-gradle action can be used to configure Gradle for optimal execution on any platform supported by GitHub Actions.

This replaces the previous gradle/gradle-build-action, which now delegates to this implementation.

The recommended way to execute any Gradle build is with the help of the Gradle Wrapper, and the examples assume that the Gradle Wrapper has been configured for the project. See this example if your project doesn't use the Gradle Wrapper.

Example usage

name: Build

on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout sources
      uses: actions/checkout@v6
    - name: Setup Java
      uses: actions/setup-java@v5
      with:
        distribution: 'temurin'
        java-version: 17
    - name: Setup Gradle
      uses: gradle/actions/setup-gradle@v6
    - name: Build with Gradle
      run: ./gradlew build

See the full action documentation for more advanced usage scenarios.

The dependency-submission action

Generates and submits a dependency graph for a Gradle project, allowing GitHub to alert about reported vulnerabilities in your project dependencies.

The following workflow will generate a dependency graph for a Gradle project and submit it immediately to the repository via the Dependency Submission API. For most projects, this default configuration should be all that you need.

Simply add this as a new workflow file to your repository (eg .github/workflows/dependency-submission.yml).

name: Dependency Submission

on:
  push:
    branches: [ 'main' ]

permissions:
  contents: write

jobs:
  dependency-submission:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout sources
      uses: actions/checkout@v6
    - name: Setup Java
      uses: actions/setup-java@v5
      with:
        distribution: 'temurin'
        java-version: 17
    - name: Generate and submit dependency graph
      uses: gradle/actions/dependency-submission@v6

See the full action documentation for more advanced usage scenarios.

The wrapper-validation action

The wrapper-validation action validates the checksums of all Gradle Wrapper JAR files present in the repository and fails if any unknown Gradle Wrapper JAR files are found.

The action should be run in the root of the repository, as it will recursively search for any files named gradle-wrapper.jar.

Starting with v4 the setup-gradle action will perform wrapper validation on each execution. If you are using setup-gradle in your workflows, it is unlikely that you will need to use the wrapper-validation action.

Example workflow

name: "Validate Gradle Wrapper"

on:
  push:
  pull_request:

jobs:
  validation:
    name: "Validation"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: gradle/actions/wrapper-validation@v6

See the full action documentation for more advanced usage scenarios.

S
Description
A collection of GitHub Actions to accelerate your Gradle Builds on GitHub
Readme MIT
336 MiB
Languages
TypeScript 60.4%
Groovy 16.9%
Shell 15%
Batchfile 4.9%
JavaScript 1.7%
Other 1.1%