6b92be1905 Update dependencies (#1065)
Rolls the outstanding dependency updates into a single change, along
with fixes for two breaking
changes they brought with them.

## Gradle Wrapper 9.6.1 → 9.7.1

Updated in all five wrapped projects: `sources/test/init-scripts` and
the `gradle-plugin`,
`groovy-dsl`, `java-toolchain` and `kotlin-dsl` workflow samples.

## GitHub Actions

- `actions/setup-java` v5.7.0 → v6.0.0
- `github/codeql-action/init` and `github/codeql-action/analyze`
re-pinned to a newer v3.29.5 commit

## npm dependencies

- `@typescript-eslint/eslint-plugin` 8.66.0 → 8.69.0
- `esbuild` 0.28.1 → 0.28.2
- `eslint` 10.8.0 → 10.9.1
- `globals` 17.9.0 → 17.11.0

`jest` stays at 30.4.2 and `@jest/globals` at 30.4.1 — see below.

## setup-java v6 needs signature verification disabled for EOL JDKs

v6 enables `verify-signature` by default. Temurin 16 and 20 are EOL and
publish no signatures, so
the toolchain-detection job could no longer install them:

```
Java setup process failed due to: Input 'verify-signature' is enabled,
but no signature URL was found for Temurin version 16.0.2+7.
```

Verification is disabled for those two steps only. The Java 17 and
matrix steps still verify.

## jest is held at 30.4.x because 30.5.0 breaks nock

jest 30.5.0 reworked the ESM module registry (ES modules keyed by full
URL, modules shared across
overlapping CommonJS/ESM graphs). nock ends up patching a different
module instance than the one
`@actions/http-client` reaches undici through, so it no longer
intercepts anything: all five mocked
tests in `short-lived-token.test.ts` silently hit the real network and
resolve `null`. Two further
tests in that file keep passing only vacuously — they assert `null`,
which is also what an
unintercepted request returns.

Bisected on node 24.18.0, changing only the jest version:

| jest | result |
| --- | --- |
| 30.5.0 | 5 failed, 38 passed |
| 30.4.2 | 43 passed |

nock 15.0.0 does not fix it, so this cannot be resolved by moving nock
forward. The node version
matters too: 24.3.0 masks the failure completely, which is why it
reproduced only in CI.

Because `jest` is an exactly-pinned direct devDependency, the pin by
itself holds the entire test
runtime at 30.4.x — `jest-cli`, `jest-runtime`, `jest-environment-node`,
`@jest/core`,
`@jest/transform`, `@jest/types`, `expect` and `jest-util` all resolve
to 30.4.x with no `overrides`
block. Nothing in the tree forces jest forward; only dependabot proposes
it. So the constraint is
expressed in `.github/dependabot.yml`, alongside the existing
`typescript` and `@types/node`
entries, ignoring `jest` and `@jest/globals` `>=30.5.0` with a comment
recording when it can be
lifted.

`pretty-format` is left to float to 30.5.1 via the types-only
`@types/jest`; it renders test output
and has no bearing on nock or module resolution.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Signed-off-by: bot-githubaction <bot-githubaction@gradle.com>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: bot-githubaction <bot-githubaction@gradle.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-07 16:58:55 -06:00
2026-09-07 16:58:55 -06:00
2026-09-07 22:35:18 +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
341 MiB
Languages
TypeScript 60.4%
Groovy 16.9%
Shell 15%
Batchfile 4.9%
JavaScript 1.7%
Other 1.1%