No description
  • TypeScript 77.2%
  • Groovy 21.4%
  • JavaScript 1.1%
  • Shell 0.3%
Find a file
Iñaki Villar c8a326d857
Authenticate CI to Develocity with workload identity (#1109)
## Changes

Moves the workflows that publish to solutions.develocity.cloud from the
long-lived `DV_SOLUTIONS_ACCESS_KEY` to GitHub OIDC tokens, using
Develocity workload identity.

- **`ci-check-and-unit-test.yml` and `ci-update-dist.yml`**: the
Develocity npm agent reads `DEVELOCITY_ACCESS_KEY` directly, and an OIDC
token can't be used there. A pre-step mints the OIDC token and exchanges
it at `/api/auth/token?expiresInHours=2`, the call setup-gradle makes,
for a short-lived Develocity access token. The npm steps read it from
`steps.develocity-oidc.outputs.token-access-key`.
- **`demo-job-summary.yml`** (`develocity-access-key-set` job): a
pre-step mints the OIDC token and passes it to `setup-gradle` as
`develocity-access-key` in `host=token` form. setup-gradle exchanges it,
the same as it does with an access key.

Each job gets `id-token: write`. Pull requests from forks get no OIDC
token, just as they get no secrets today: the step warns and exits
cleanly, and the builds run unauthenticated.

## Not in this PR

`suite-integ-test-other.yml` still passes `DV_SOLUTIONS_ACCESS_KEY` to
`integ-test-inject-develocity.yml`. Those jobs test setup-gradle's own
access-key handling: swapping a classic access key for a short-lived
token, the `GRADLE_ENTERPRISE_ACCESS_KEY` variant, and not leaking the
key when the exchange fails. Feeding them an OIDC token would still run
the exchange, but would stop covering the classic access-key path.
Should they keep a long-lived key on purpose?

## Verification

- [x] CI-check-and-unit-test on this PR ([run
41095618008](https://github.com/gradle/actions/actions/runs/41095618008)):
green, the OIDC token is exchanged, and the npm agent published Build
Scans to solutions.develocity.cloud, for example
[ejvi6m5cprrhg](https://solutions.develocity.cloud/s/ejvi6m5cprrhg) and
[goncdygtosovo](https://solutions.develocity.cloud/s/goncdygtosovo)
- [x] Demo Job Summary dispatched on this branch ([run
41095628373](https://github.com/gradle/actions/actions/runs/41095628373)),
`develocity-access-key-set` job: green, setup-gradle logs `Requesting
short-lived Develocity access token for solutions.develocity.cloud` with
no warning. The sample project publishes to scans.gradle.com, as before.
- [ ] CI-update-dist runs only on `main`/release branches and commits
`dist`, so it is verified after merge
2026-10-30 11:08:40 -07:00
.github Authenticate CI to Develocity with workload identity 2026-10-30 10:04:20 -07:00
dependency-submission Add cache-provider: external to skip Gradle User Home caching (#1059) 2026-08-25 09:44:41 -06:00
dist [bot] Update dist directory 2026-10-28 12:28:40 +00:00
docs Combined dependency updates (#1105) 2026-10-28 05:38:06 -06:00
licenses Extract caching logic into a separate gradle-actions-caching component (#885) 2026-03-18 14:57:27 -06:00
setup-gradle Add cache-provider: external to skip Gradle User Home caching (#1059) 2026-08-25 09:44:41 -06:00
sources Merge commit from fork 2026-10-28 13:28:01 +01:00
wrapper-validation Improve typings (#938) 2026-06-10 08:54:56 -06:00
.gitignore Report EOL and maintenance status for Gradle versions (#1057) 2026-09-07 16:34:26 -06:00
.tool-versions Update .tool-versions: node 24.18.0, gradle 9.7.1, java 17 (#1068) 2026-09-07 17:59:30 -06:00
action.yml Move top-level action to 'setup-gradle' 2024-01-25 11:53:44 -07:00
actions.code-workspace Include VS code workspace file 2024-04-12 15:39:30 -06:00
build Convert project to ESM and update dependencies (#854) 2026-02-10 15:30:49 -07:00
CLAUDE.md Add open-source 'basic' cache provider and revamp licensing documentation (#930) 2026-04-02 21:36:01 -06:00
CODE_OF_CONDUCT.md add code of conduct 2019-09-21 20:57:04 +02:00
CONTRIBUTING.md Improve local development script 2024-11-14 17:00:58 -07:00
DISTRIBUTION.md Link to docs for caching providers 2026-04-03 08:42:14 -06:00
LICENSE Revise license details for gradle-actions-caching 2026-04-03 07:48:43 -06:00
NOTICE Update license link for gradle-actions-caching component 2026-04-03 07:47:03 -06:00
README.md Update docs for v6 2026-04-03 15:25:10 -06:00
RELEASING.md Document immutable releases in the release process 2026-08-02 13:54:30 -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.