Updates the default version of the [GitHub Dependency Graph Gradle
Plugin](https://plugins.gradle.org/plugin/org.gradle.github-dependency-graph-gradle-plugin)
applied by the `dependency-submission` init-script from `1.4.2` to
`1.5.0`.
`1.5.0` is the latest version published to the Gradle Plugin Portal.
Users can still override this via the `dependency-graph-plugin.version`
input parameter (`DEPENDENCY_GRAPH_PLUGIN_VERSION`), so this only
changes the default.
## Notes
The init-script is read at runtime from `sources/src/resources` rather
than being inlined into the bundle, so this single source change is the
whole fix — no `dist` update is needed for the new version to take
effect (CI refreshes `dist` as usual).
## Verification
- `npm run check` (prettier + eslint) passes
- `npm run test`: 489 passed. The 2 failing wrapper-validation suites
are pre-existing network-dependent failures on this machine — confirmed
identical on a clean tree with this change stashed
- Confirmed `1.5.0` is published to the plugin portal (and that a bogus
version 404s, so the check is meaningful)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
Combines three pending automated update PRs into a single pull request
so they can be reviewed and merged together.
Supersedes:
- #1045 — Update known wrapper checksums
- #1066 — Bump the npm-dependencies group in /sources (eslint 10.9.1 →
10.10.0, globals 17.11.0 → 17.12.0)
- #1067 — Bump actions/setup-java from 5.7.0 to 6.0.0 in the
github-actions group
Each original commit is cherry-picked unchanged; there were no
overlapping files or conflicts.
## Verification
- `./build install` (clean install + format + lint + compile) passes.
- `./build test`: 490/491 pass. The single failure is
`wrapper-validation/checksums.test.ts › fetches wrapper jar checksums
for snapshots`, a pre-existing network-dependent failure on this machine
— it fails identically with `main`'s checksums file, so it is unrelated
to these changes.
- `dist/` is intentionally untouched; CI regenerates it.
---------
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: bot-githubaction <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.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 <[email protected]>
Co-authored-by: Daz DeBoer <[email protected]>
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
Develocity access keys have the format `server=key[;server=key]*`. The
short-lived-token code validated that format with:
```
/^([^;=\s]+=\w+)(;[^;=\s]+=\w+)*$/
```
This is too strict about `key`, and an OIDC token value fails it. There
were two independent problems:
1. `\w+` rejects the `.`, `-`, `_` and `=` padding a JWT contains.
2. Even had the regex passed, `parse` split each entry with
`hostKey.split('=')` and took `pair[1]`, so a key containing `=` would
have been **silently truncated** — a worse failure than rejection, since
the mangled key would then be sent to the server.
## Change
Drop `accessKeyRegexp` and the separate `isValid` gate; validate
structurally in `parse` instead, asserting only what is needed to split
the value:
- split on `;`, then split each entry on its **first** `=` only
- hostname: non-empty and free of whitespace (it cannot contain `=` or
`;` by construction)
- key: non-empty and free of whitespace — nothing else is assumed about
its shape
Two small intentional behaviour deltas beyond the fix:
- The whole value is now trimmed, so a trailing newline on a secret no
longer rejects the key. Internal whitespace still rejects.
- Empty entries (`host=key;`, `;host=key`) still reject, as before.
## Testing
Added cases to `short-lived-token.test.ts`: a JWT-shaped key value,
first-separator-only splitting (`host1=a=b==` → key `a=b==`),
surrounding-whitespace tolerance, a `raw()` round-trip preserving `==`
padding, and a table of nine rejection cases. 32 tests pass; prettier,
eslint and `./build` are clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
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 <[email protected]>
Job summaries from setup-gradle/dependency-submission had no top-level
heading, so they read poorly when another action's summary content lands
in the same job. Name the action explicitly so the block is attributable
when summaries are stacked.
---------
Co-authored-by: Claude Sonnet 5 <[email protected]>
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] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
Co-authored-by: bot-githubaction <[email protected]>
Supersedes #1023.
## 1. Adjust dependabot's TypeScript choices
Dependabot's group bump included two changes that we don't want to take
as-is:
- **typescript**: `5.9.3` → `7.0.2`. Pinned to **6.0.3** instead.
- **@types/node**: `25.9.2` → `26.1.1`. Downgraded to the latest 24.x
(**24.13.3**), matching the Node 24 runtime the actions target.
All other updates from #1023 are kept unchanged (`@actions/cache` 6.2.0,
`semver` 7.8.5, `@typescript-eslint/eslint-plugin` 8.65.0, `esbuild`
0.28.1, `eslint` 10.7.0, `globals` 17.7.0, `prettier` 3.9.6, `ts-jest`
29.4.12), and the branch is rebased onto current `main`.
The prettier 3.9.6 bump reformats two union types in
`sources/src/cache-service.ts`; that reformatting is included so `npm
run check` passes.
## 2. Clear 5 open security advisories
`npm audit` reported 4 high and 1 low severity advisory. All are fixable
with **semver-compatible transitive updates** — `npm audit fix` clears
them without `--force`, and `package.json` is untouched.
**Production** (bundled into `dist/`, so they ship in the actions):
| Package | Before | After | Via |
| --- | --- | --- | --- |
| `undici` | 6.24.1 | 6.28.0 | `@actions/github`, `@actions/http-client`
|
| `undici` | 7.24.5 | 7.29.0 | `cheerio` |
| `brace-expansion` | 5.0.6 | 5.0.9 | `@actions/glob` → `minimatch` |
| `brace-expansion` | 2.0.3 | 2.1.4 | `@actions/artifact` → `archiver` |
**Dev only:** `shell-quote` 1.8.4 → 1.10.0 (`npm-run-all`), `js-yaml`
3.14.2 → 3.15.1 (`ts-jest`), `@babel/core` 7.28.0 → 7.29.x (`ts-jest`,
low severity).
These were outstanding because the lockfile pins transitive resolutions
while `.github/dependabot.yml` only bumps direct dependencies. Because
`undici` and `brace-expansion` are production dependencies, the bundled
`dist/` output will change when the update-dist bot runs.
## 3. Downgrade nock to 14.0.17
**nock 15.0.0 was published by mistake.** The registry marks it
deprecated:
> v15.0.0 was released accidentally and is unstable. Please use v14.x
until v15 is officially ready.
nock's `latest` dist-tag still points at 14.0.17 for exactly this
reason, and 15.x remains a beta line (`beta` = `15.0.0-beta.14`).
Dependabot picked up 15.0.0 in an earlier group bump simply because it
is the highest published version. This moves us to 14.0.17, pulling
`@mswjs/interceptors` 0.39.8 → 0.41.9 and adding `propagate` 2.0.1.
Dependabot will likely re-propose nock 15.0.0 on its next weekly run,
since no ignore rule was added.
## 4. Delete unused `sources/.nvmrc`
The file pinned Node `v16`, contradicting `package.json` engines
(`>=24.0.0`), the esbuild `node24` target, and `.tool-versions` (`nodejs
24.3.0`). Nothing reads it — no workflow uses `node-version-file` and
there are no other references in the repo. Stale since 5e522253.
## 5. Run CI workflows on Node 24
`ci-check-and-unit-test.yml`, `ci-update-dist.yml`, and
`update-checksums-file.yml` pinned `node-version: 20`, so `npm
clean-install` was emitting `EBADENGINE` warnings for the root package
against its own `engines: >=24.0.0`. All three now use Node 24, matching
`.github/actions/build-dist/action.yml`.
Worth noting: `ci-update-dist.yml` built `dist/` on Node 20 in its
inline steps while `build-dist/action.yml` built it on Node 24, so the
committed distribution could previously be produced under either
version.
## Verification
- `./build` — clean
- `npm run check` (prettier + eslint) — clean
- `npm test` — 373 tests, 15 suites, all passing
- `npm audit` — **found 0 vulnerabilities** (was 4 high, 1 low)
- `npx tsc --noEmit` — one pre-existing error in
`@octokit/request-error` types (`Cannot find name 'ErrorOptions'`),
identical on `main` with TypeScript 5.9.3, so not a regression. `tsc` is
not part of the build or CI.
A clean regeneration of `package-lock.json` from `package.json` was also
evaluated. It likewise yields 0 vulnerabilities and 373 passing tests,
but churns 80 transitive packages including the `@azure/core-*` /
`@azure/storage-blob` stack used by `@actions/cache`. Since it offers no
security benefit over the current lockfile, it was not adopted.
### Known-failing checks (pre-existing on `main`)
The three `smoke-tests / restore-gradle-home / … (windows-latest)` jobs
fail with `Build was not cached: unexpected execution of test task`. The
identical three jobs fail on `main` in run
[30723964208](https://github.com/gradle/actions/actions/runs/30723964208),
on the very commit this branch is based on, so they are not caused by
these changes.
## Not included
`npm outdated` also shows `eslint` 10.7.0 → 10.8.0 and `globals` 17.7.0
→ 17.8.0. Both are dev-only and dependabot's weekly npm group run will
propose them.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
Follow-up to #1027, which added Windows coverage for the caching smoke
tests. `basic-cache-verify-build` failed on Windows for a reason
unrelated to #1013.
## Root cause
The Windows seed job **never uploaded a cache entry, but reported that
it did**. `gh cache list` showed no `setup-java-Windows-*` entry at all,
despite the job logging `Basic caching saved entry with key:
setup-java-Windows-x64-gradle-594edf…`. The keys were never the problem
— seed and verify requested the identical key.
The seed build leaves a Gradle daemon running, holding the `*.lock`
files in the Gradle User Home. On Windows those locks are mandatory, so
`tar` cannot read them:
```
/usr/bin/tar: ../../.gradle/caches/modules-2/modules-2.lock: Read error at byte 0,
while reading 38 bytes: Device or resource busy
/usr/bin/tar: Exiting with failure status due to previous errors
```
38 bytes is exactly Gradle's lock-file header — the region the daemon
holds via `FileChannel.lock()`. On Linux the lock is advisory and tar
reads straight through, which is why this only ever failed on Windows.
`cache.saveCache()` catches the tar failure, logs it, and returns `-1`
rather than throwing. `BasicCacheService.save()` ignored the return
value, so the seed job went green and the failure surfaced only later —
as a plugin resolution error in the verify job, pointing nowhere near
caching.
## Changes
**1. Warn when the save fails.** Check the returned `cacheId` and, when
it is `-1`, emit a warning and report `(Entry not saved: save failed)`
in the job summary. Caching failures still do not fail the build.
**2. Run the seed build with `--no-daemon`.** Daemon management for
enhanced caching lives in the `gradle-actions-caching` library; basic
caching leaves it to the workflow, so the smoke test now ensures no
daemon is holding locks when the post-action save runs.
## Not related to #1013
The enhanced provider fails differently on Windows — every entry dies at
path validation, before tar runs (`Path Validation Error: Path(s)
specified in the action for caching do(es) not exist`). Same symptom,
different mechanism; that one is unchanged here and is still expected to
be red.
## Verification
`npm run check` and `npm test` pass locally (373 tests). The real check
is this PR's Windows run: `basic-cache-seed-build` and
`basic-cache-verify-build` should both be green on `windows-latest`,
while the `restore-gradle-home-*` Windows jobs stay red pending the
#1013 fix.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
## Problem
The `dependency-submission` action disables Isolated Projects for the
dependency-resolution build by passing
`-Dorg.gradle.unsafe.isolated-projects=false`.
Recent Gradle versions have promoted the property to
`org.gradle.isolated-projects`. A build that enables IP via the promoted
property (e.g. `gradle/gradle`, see [this failing
run](https://github.com/gradle/gradle/actions/runs/30357651750/job/90269499556?pr=38402))
is no longer disabled by the unsafe spelling, so the build runs with IP
enabled and fails:
```
Error resolving plugin [id: 'gradlebuild.build-environment']
> Project ':build-logic-settings' cannot access 'Project.tasks' functionality on subprojects via 'allprojects'
```
(`ForceDependencyResolutionPlugin` is not IP-compatible.)
## Fix
Pass both spellings of the property. `-D` system properties that Gradle
does not recognize are silently ignored, so this is safe for all
supported Gradle versions — the action already passes the unsafe
spelling to pre-IP Gradle versions without issue.
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]>
Render the configuration-cache restore-state in the caching Job Summary,
driven by the new `CacheReport.configurationCache` field produced by the
`gradle-actions-caching` provider.
## What's here
- `cache-service.ts`: add a `ConfigurationCacheStatus` type
(`not-active` / `restored` / `not-restored` / `restore-incomplete`) and
an optional `configurationCache` field on `CacheReport`.
- `caching-report.ts`: a `CONFIG_CACHE_COPY` map and a prominent status
line in `renderCachingReport`, beside the cleanup line. The `not-active`
case links to the `#cache-encryption-key` docs.
## Cross-repo dependency
The field is populated by gradle/actions-caching PR #75 ("Restore
configuration-cache support for simple builds"). This rendering compiles
independently (it uses this repo's own `CacheReport` type) and renders
nothing until the vendored `gradle-actions-caching` bundle is refreshed
from that branch — so this should land with/after the vendor refresh.
## Verification
`npm run check` clean; full Jest suite (366 tests) passes, including 3
new rendering tests.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
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]>
- 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 <[email protected]>
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
Automatically generated pull request to update the known wrapper
checksums.
In case of conflicts, manually run the workflow from the [Actions
tab](https://github.com/gradle/actions/actions/workflows/update-checksums-file.yml),
the changes will then be force-pushed onto this pull request branch.
Do not manually update the pull request branch; those changes might get
overwritten.
> [!IMPORTANT]
> GitHub workflows have not been executed for this pull request yet.
Before merging, close and then directly reopen this pull request to
trigger the workflows.
Co-authored-by: bot-githubaction <[email protected]>
## 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) <[email protected]>
This pull request includes dependency updates, a minor bug fix, and a
workflow update. The most significant changes are grouped below:
Dependency Updates:
* Updated several development dependencies in `sources/package.json`,
including `@typescript-eslint/eslint-plugin` to 8.58.0, `esbuild` to
0.28.0, and `ts-jest` to 29.4.9, to keep the project up to date with the
latest features and bug fixes.
Bug Fix:
* Fixed a typo in the import statement for `deprecation-collector` in
`sources/src/configuration.ts`, correcting the import from `de cator` to
`deprecator`.
CI/CD Workflow Update:
* Updated the commit hashes for the `github/codeql-action/init` and
`github/codeql-action/analyze` steps in
`.github/workflows/ci-codeql.yml` to use a newer commit, ensuring the
workflow uses the latest patches for these actions.
---------
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This is necessary to avoid loading a cache entry from a different test,
where the allowed wrapper checksums might have been cached, causing the
wrapper validation to unexpectedly succeed.
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.
Removes support for configuration-cache extraction and restore from the
caching workflow and related source code. Configuration-cache support
only worked for a limited set of projects (gradle/actions#21), and we
plan to reimplement this properly as part of the
`gradle-actions-caching` project.
The main impact is simplification of the caching logic, focusing only on
common Gradle artifacts. The `ConfigurationCacheEntryExtractor` class
and related logic were deleted from
`sources/src/caching/gradle-home-extry-extractor.ts`.
Automatically generated pull request to update the known wrapper
checksums.
In case of conflicts, manually run the workflow from the [Actions
tab](https://github.com/gradle/actions/actions/workflows/update-checksums-file.yml),
the changes will then be force-pushed onto this pull request branch.
Do not manually update the pull request branch; those changes might get
overwritten.
> [!IMPORTANT]
> GitHub workflows have not been executed for this pull request yet.
Before merging, close and then directly reopen this pull request to
trigger the workflows.
Co-authored-by: bot-githubaction <[email protected]>
Co-authored-by: Jérôme Prinet <[email protected]>
Automatically generated pull request to update the known wrapper
checksums.
In case of conflicts, manually run the workflow from the [Actions
tab](https://github.com/gradle/actions/actions/workflows/update-checksums-file.yml),
the changes will then be force-pushed onto this pull request branch.
Do not manually update the pull request branch; those changes might get
overwritten.
> [!IMPORTANT]
> GitHub workflows have not been executed for this pull request yet.
Before merging, close and then directly reopen this pull request to
trigger the workflows.
Co-authored-by: bot-githubaction <[email protected]>
Co-authored-by: Jérôme Prinet <[email protected]>
Automatically generated pull request to update the known wrapper
checksums.
In case of conflicts, manually run the workflow from the [Actions
tab](https://github.com/gradle/actions/actions/workflows/update-checksums-file.yml),
the changes will then be force-pushed onto this pull request branch.
Do not manually update the pull request branch; those changes might get
overwritten.
> [!IMPORTANT]
> GitHub workflows have not been executed for this pull request yet.
Before merging, close and then directly reopen this pull request to
trigger the workflows.
