Follow-up to #1069, which bumped the
`github-dependency-graph-gradle-plugin` default to `1.5.0`.
`1.5.0` is signed with a **new** Gradle signing subkey, and the key
currently documented in `docs/setup-gradle.md` has been revoked
upstream. Without this docs change, the snippet we publish will fail
dependency verification for Dependency Graph generation.
I verified the published signatures rather than relying on the
changelog:
| Artifact | Issuer key | |
|---|---|---|
| `github-dependency-graph-gradle-plugin:1.5.0` | `D9B2DFBD9F3298BA` |
new |
| `github-dependency-graph-gradle-plugin:1.4.2` | `893A028475557671` |
old |
| `develocity-gradle-plugin:4.5.0` | `893A028475557671` | old |
So the docs now list **both** keys instead of swapping one for the
other. The Develocity Gradle plugin (`com.gradle`) is still signed with
the old key, so replacing it outright would have broken Develocity
injection for builds with dependency verification enabled.
Docs-only change; no source or `dist` impact.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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 <louis@gradle.com>
Co-authored-by: Daz DeBoer <daz@gradle.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Replaces the unqualified `wrapper` task name with the
root-project-qualified
`:wrapper` in the two places this repo names it:
- `.github/workflows/demo-job-summary.yml` — the kotlin-dsl sample
invocation
- `docs/wrapper-validation.md` — the guidance for regenerating an
unverifiable
`gradle-wrapper.jar`
An unqualified `wrapper` matches the task in every project of a
multi-project
build. The root-qualified form is unambiguous, matches the gradle/gradle
convention, and is required under Configure on Demand.
Part of the org-wide rollout tracked in gradle/gradle-private#5228;
original
issue gradle/gradle#37761.
Signed-off-by: Christoph Obexer <cobexer@gradle.com>
Users relying on an external mechanism to save/restore Gradle User Home
(e.g. Develocity Artifact Cache) previously had to set cache-disabled:
true, which is confusing since caching isn't actually disabled — it's
just not managed by this action — and the Job Summary misleadingly
reported caching as "Disabled".
cache-provider: external skips Gradle User Home restore/save (same as
cache-disabled) but reports a distinct "External" status in the Job
Summary, explaining that caching is handled by another provider.
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Consolidates seven open bot PRs into three commits.
## 1. Bump Gradle Wrapper from 9.5.1 to 9.6.1
Combines **#1008, #1009, #1010, #1011, #1012** into a single commit.
Each of those PRs bumped the wrapper in one directory; this covers all
five (15 files):
- `sources/test/init-scripts`
- `.github/workflow-samples/gradle-plugin`
- `.github/workflow-samples/groovy-dsl`
- `.github/workflow-samples/java-toolchain`
- `.github/workflow-samples/kotlin-dsl`
Each location gets the same `distributionUrl` → `gradle-9.6.1-bin.zip`
and `distributionSha256Sum` update, plus the regenerated `gradlew` /
`gradlew.bat` scripts.
## 2. Update known wrapper checksums
**#990**, unchanged, as its own commit. Adds 36 checksum entries to
`sources/src/wrapper-validation/wrapper-checksums.json`, **including the
9.6.1 checksums** — which is what lets the wrapper bump above pass
`CI-validate-wrappers`. These two are worth landing together.
## 3. Bump Develocity Gradle plugin from 4.4.2 to 4.5.0
**#1015**, unchanged, as its own commit. Updates the plugin reference
across workflow samples, init-script tests, docs, and the injected
default in `sources/src/develocity/build-scan.ts`:
```diff
-maybeExportVariable('DEVELOCITY_INJECTION_DEVELOCITY_PLUGIN_VERSION', '4.4.2')
+maybeExportVariable('DEVELOCITY_INJECTION_DEVELOCITY_PLUGIN_VERSION', '4.5.0')
```
Since this touches `sources/src`, the bundled `dist/` will change when
the update-dist bot runs.
## Verification
All three cherry-picks applied without conflicts. On the combined
branch:
- `./build` — clean
- `npm run check` (prettier + eslint) — clean
- `npm test` — 373 tests, 15 suites, all passing
Original bot authorship is preserved on all three commits.
## Superseded PRs
Once this merges, these can be closed: #1008, #1009, #1010, #1011,
#1012, #990, #1015.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: bot-githubaction <bot-githubaction@gradle.com>
- Injects a `<!-- gradle-job-summary: ${jobCorrelator} -->` marker on
each job summary
- Lists 100 last comments: unfortunately there is no API to specifically
filter for comments, and checking the last 100 comments (the limit) is
usually enough and does not require iterating over pages
- Mutate comments having this expected marker
I tried to add some tests, but I'm not familiar enough to setup a
complete test suite with proper mocking of GitHub/Octokit with jest.
I could potentially extract the `prComment` creation to check for the
marker presence, let me know.
Note: it seems like there is currently an issue on mutating comments as
`OUTDATED` through graphql. Although it does not work as expected
(flagging as OUTDATED) the comments are still minimized, which is what
we want.
- https://github.com/orgs/community/discussions/19865
Implements #176
---------
Co-authored-by: Daz DeBoer <daz@gradle.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Summary
- Reorganized setup-gradle caching docs into three clear sections:
general (shared options), Enhanced Caching, and Basic Caching
- Added new documentation for `cache-encryption-key`,
`gradle-home-cache-strict-match`, and the full Basic Caching section
(key strategy, stored content, limitations)
- Moved enhanced-only options (`cache-write-only`,
`cache-overwrite-existing`, `cache-cleanup`, includes/excludes, strict
matching) into the Enhanced Caching section
- Preserved all existing anchor links used by source code and other docs
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
- **New `basic` cache provider**: Adds an open-source (MIT-licensed)
caching implementation built on `@actions/cache` as an alternative to
the proprietary Enhanced Caching. Users can opt in with `cache-provider:
basic` on both `setup-gradle` and `dependency-submission` actions.
- **Revamped licensing & distribution docs**: Replaces the verbose
licensing notice block (previously shown in README, docs, and logs) with
a friendlier callout and a new dedicated
[DISTRIBUTION.md](./DISTRIBUTION.md) covering component licensing, usage
tiers, data privacy ("Safe Harbor"), and opt-out instructions.
- **Improved messaging**: Enhanced Caching and Basic Caching each
display concise, informative log messages and job summary notes instead
of the previous wall-of-text license warning.
- **New integration tests**: Adds `integ-test-basic-cache-provider.yml`
workflow that seeds and verifies the basic cache provider across
platforms, plus unit tests for `BasicCacheService` and `getCacheService`
selection logic.
- **CI workflow reorganization**: Dependency-submission integration
tests extracted into their own reusable suite
(`suite-integ-test-dependency-submission.yml`); sample project tests
moved into the caching suite.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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.
Due to an issue with dependency-review-action (https://github.com/gradle/actions/issues/482),
the setup described in the documentation can result in duplicate
dependencies being added to the dependency graph.
To avoid this, we now recommend using a common `dependency-submission`
workflow for both pushes to `main` and pull requests.
The `dependency-review` workflow runs on any `pull_request` but will wait
for the `dependency-submission` to complete.
This setup works for both the standard setup, and for the advanced setup for
pull requests from repository forks.
This change primarily impacts test projects and documentation. The only
material impact is that CCUD 2.1 will now be auto-applied when
publishing Build Scans automatically with `build-scan-publish: true`.
(Develocity injection does not hard-code any CCUD version)
Diagnosing unexpected dependencies in the GitHub Dependency Graph can
be difficult. In order to aid with diagnosis, the `dependency-submission`
action will now save each dependency-graph file as a workflow artifact.
If this is undesirable, the prior behaviour can be restored by explicitly setting
`dependency-graph: generate-and-submit`.
Fixes#519
