This PR reports the support status of every Gradle version used in a
workflow:
- **End-of-life** — two or more major versions behind the latest
release.
- **Out of date** — one major version behind the latest release, or more
than two minor versions behind on the current major.
The information is surfaced as job annotations and in the Job Summary:
an icon beside the Gradle version in the build results table, and a
message below it.
| version kind | job annotation | version table | below the table |
| ------ | ----- | ---- | --------- |
| EOL | warning | ⚠️ | expandable section, pointing to the Gradle
Security Subscription |
| Out of date | notice | ℹ️ | one-line legend, pointing to the Gradle
release lifecycle docs |
| Current | none | — | — |
A single expandable section covers every end-of-life version, naming
them in its summary line and listing the affected release lines in its
body. The upgrade legend likewise appears once per job, however many
versions carry the info icon.
Notes on what is deliberately *not* reported:
- **Patch releases.** Only the major and minor version are considered,
so being on `9.7.0` when `9.7.1` exists is not flagged.
- **Pre-releases.** Release candidates, milestones and snapshots are
never reported, so testing against a nightly or an RC produces no
annotations.
The latest Gradle release is determined from the wrapper checksum data
already bundled with the action, so no network access is required. That
data is refreshed weekly, and the two-minor grace band absorbs the lag.
Note that the annotations are emitted independently of
`add-job-summary`: setting it to `never` suppresses the Job Summary
itself, but the warning and notice annotations remain.
### Examples
The `demo-job-summary` workflow has a `support-status-eol-and-outdated`
job that builds with three end-of-life versions (`6.9.4`, `7.4`,
`7.6.6`), two out-of-date versions (`8.0.2`, `8.14.5`) and the current
release, so all three statuses appear in one summary:
* **Job Summary**:
https://github.com/gradle/actions/actions/runs/34166688755#summary-101879071306
* **Annotations**:
https://github.com/gradle/actions/actions/runs/34166688755/job/101879071306
(expand annotations)
That workflow is never triggered automatically; run it manually against
a branch to review the rendering.
### Implementation
* Adds `GradleVersion`, parsing and ordering versions the same way
Gradle's own `org.gradle.util.GradleVersion` does. This replaces the
previous `versionIsAtLeast` helper and removes the `semver` dependency.
* Adds `gradle-support-status.ts`, which owns the classification policy
and both of its presentations (annotations and Job Summary section)
behind a three-function API, so `job-summary.ts` only asks for the icon
and the rendered block.
### Testing
* Unit tests for version ordering, classification, the annotations and
the rendered summary.
* `integ-test-gradle-support-status.yml`, which derives its expected
versions from the bundled release data so the assertions cannot drift
from the action's own view, then asserts against the real job log.
* The demo workflow job linked above, for reviewing the rendering by
eye.
Documented under [Build
reporting](https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#gradle-version-support-status)
in `docs/setup-gradle.md`.
---------
Co-authored-by: Louis Jacomet <[email protected]>
Co-authored-by: Daz DeBoer <[email protected]>
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
Pass develocityAccessToken and develocityServerUrl the
`gradle-actions-caching`: required to support project-entry caching
(build-logic + configuration-cache), which has experimental support in
'[email protected]. This support is not yet released and will
be available as a restricted trial.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
Redesigns the caching section of the Job Summary into a single,
consistent layout across every cache provider and state, and integrates
the provider message into the report rather than appending it
disconnected at the bottom.
## Motivation
The caching report was produced by three divergent code paths (NoOp /
basic / enhanced), each rendering its own markdown:
- **Explicitly disabled** → a one-line message, no expand, no provider
note.
- **Enhanced** (incl. skipped-due-to-existing-home) → a full `<details>`
block.
- **Basic** → a one-line message with **no** expandable details at all.
The Enhanced/Basic provider note floated at the very bottom,
disconnected from the report.
## What changed
`save()` now returns structured `CacheReport` data instead of
pre-rendered HTML, and a single renderer (`caching-report.ts`) produces
one unified layout for all variants:
- **Section heading**: `#### <icon> Gradle Caching — <Provider>
(<status>)`
- **Status line** explaining what the cache did
- **Integrated provider note** woven in under the heading — now shown
**unconditionally** (no longer gated on license acceptance)
- **Expandable cache-entry details** when there are entries — basic
caching now gets this too
The two disabled variants (explicitly disabled, and skipped due to a
pre-existing Gradle User Home) render as **compact callouts with no
expandable section**.
### Main repo
- `caching-report.ts` (new): central renderer + all framing copy + entry
table/`<pre>` helpers.
- `cache-service.ts`: `CacheReport` / `CacheEntryReport` / status types;
`save()` returns `CacheReport`.
- `cache-service-loader.ts`: `NoOp` returns a report;
`LicenseWarningCacheService` removed; new `getProviderNote()`.
- `cache-service-basic.ts`: builds a `CacheReport`.
- `job-summary.ts` / `setup-gradle.ts`: thread `CacheReport` +
`ProviderNote`.
- `configuration.ts`: remove now-unused `isCacheLicenseAccepted()`.
### Vendored library
The structured contract requires **gradle-actions-caching v0.7.0**
(gradle/actions-caching#74). This PR updates the vendored library to
that release — the official `Update gradle-actions-caching library to
v0.7.0` vendor commit is included here, so merging this PR ships the
redesign together with the library it depends on.
## Testing
- Both repos build; prettier + eslint clean.
- `gradle/actions`: 363/363 Jest tests pass, including new
`caching-report.test.ts` covering every variant.
- `gradle-actions-caching`: 74/74 pass under JDK 17.
- Rendered markdown verified for all five variants (enhanced/basic
enabled & read-only, disabled, skipped).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Bot Githubaction <[email protected]>
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
With licensing changes in v6, a license warning was added to the logs
and job summary. Now, accepting the Build Scan Terms of Use or providing
a Develocity Access Key will mute this warning.
With this change, the caching functionality of `setup-gradle` and
`dependency-submission` is now provided by `gradle-actions-caching`, a
closed-source library distributed under our [Terms of
Use](https://gradle.com/legal/terms-of-use/). The rest of the action
implementation remains open source.
Using `setup-gradle` or `dependency-submission` with caching enabled
involves loading and using the `gradle-actions-caching` component,
requiring acceptance of the [Terms of
Use](https://gradle.com/legal/terms-of-use/). There are no functional
changes to caching provided by these actions: all workflows will
continue to function as before.
The non-caching aspects of action implementation remain open source. By
running these actions with caching disabled they can be used without
ever loading `gradle-actions-caching` or accepting the license terms.
Supporting the caching infrastructure in this project requires a
substantial engineering investment by Gradle Technologies, which we can
sustain thanks to Develocity, our commercial offering. Caching
technologies are a core part of the Develocity offering, and the caching
in `setup-gradle` fits squarely in that space.
This licensing change lets us continue to build advanced capabilities
that go beyond what we would offer as open source. Proper
production-ready Configuration Cache support will be the first
capability. Improving build performance for self-hosted runners will
follow.
We may introduce functionality restrictions in future updates. However,
caching functionality will remain free for public repositories.
We have a long-standing commitment to open source, as maintainers of
Gradle Build Tool, and by [sponsoring the open source
community](https://gradle.com/oss-sponsored-by-develocity/) with free
Develocity licenses. Public repositories are primarily used by open
source projects, and we remain committed to supporting them.
- Implementation of caching logic to save and restore Gradle User Home
content has been removed, replaced by the `gradle-actions-caching`
component.
- The `@actions/caching` library is still used to cache Gradle
distributions that are downloaded and provisioned by `setup-gradle`.
This PR updates to the latest version of `@actions/caching`, and removes
the patch that is no longer required.
- License notices are now displayed in documentation, logs and the
generated Job Summary.
The most common case for validation will be that the wrapper jars are unchanged
from a previous workflow run. In this case, we cache the validated wrapper
checksums to minimise the work required on a subsequent run.
Fixes#172
Adds new 'cache-cleanup' parameter with 3 settings: 'never', 'on-success' and 'always'.
This gives users more control over whether cache cleanup should occur.
Fixes#71
The setup-gradle action tries to get a short-lived access token given the supplied Develocity access key.
This key can be passed either with the `DEVELOCITY_ACCESS_KEY` env var or via the `develocity-access-key` input parameter.
If a token can be retrieved, then the `DEVELOCITY_ACCESS_KEY` env var will be set to the token.
Otherwise the `DEVELOCITY_ACCESS_KEY` will be set to a blank string, to avoid a leak.
---------
Co-authored-by: daz <[email protected]>
On long-lived machines, it's possible that the `.build-results` directory isn't cleared between invocations. This will result in the job summary including results from previous jobs.
By marking each build-results file as 'processed' at the end of the job, we can avoid this scenario.
Now, a `dependency-submission` step will trigger a dependency-graph
generation, even if it follows a `setup-gradle` step in the workflow.
Similarly, a `setup-gradle` step with `dependency-graph` configured
will function as expected even if it follows a `setup-gradle` step.
