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 <bot-githubaction@gradle.com>
Bumps the npm-dependencies group in /sources with 2 updates:
[@typescript-eslint/eslint-plugin](https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/eslint-plugin)
and [ts-jest](https://github.com/kulshekhar/ts-jest).
Updates `@typescript-eslint/eslint-plugin` from 8.29.1 to 8.30.1
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/typescript-eslint/typescript-eslint/releases"><code>@typescript-eslint/eslint-plugin</code>'s
releases</a>.</em></p>
<blockquote>
<h2>v8.30.1</h2>
<h2>8.30.1 (2025-04-14)</h2>
<h3>🩹 Fixes</h3>
<ul>
<li><strong>eslint-plugin:</strong> fix mistake with eslintrc config
generation (<a
href="https://redirect.github.com/typescript-eslint/typescript-eslint/pull/11072">#11072</a>)</li>
</ul>
<h3>❤️ Thank You</h3>
<ul>
<li>Kirk Waiblinger <a
href="https://github.com/kirkwaiblinger"><code>@kirkwaiblinger</code></a></li>
</ul>
<p>You can read about our <a
href="https://main--typescript-eslint.netlify.app/users/versioning">versioning
strategy</a> and <a
href="https://main--typescript-eslint.netlify.app/users/releases">releases</a>
on our website.</p>
<h2>v8.30.0</h2>
<h2>8.30.0 (2025-04-14)</h2>
<h3>🚀 Features</h3>
<ul>
<li><strong>eslint-plugin:</strong> [no-explicit-any] suggest to replace
keyof any with PropertyKey (<a
href="https://redirect.github.com/typescript-eslint/typescript-eslint/pull/11032">#11032</a>)</li>
</ul>
<h3>🩹 Fixes</h3>
<ul>
<li><strong>eslint-plugin:</strong> [promise-function-async] use a
different error message for functions with promise and non-promise types
(<a
href="https://redirect.github.com/typescript-eslint/typescript-eslint/pull/10950">#10950</a>)</li>
<li><strong>typescript-estree:</strong> use token type of
<code>PrivateIdentifier</code> instead of <code>Identifier</code> for
private identifiers (<a
href="https://redirect.github.com/typescript-eslint/typescript-eslint/pull/11023">#11023</a>)</li>
</ul>
<h3>❤️ Thank You</h3>
<ul>
<li>Dima Barabash <a
href="https://github.com/dbarabashh"><code>@dbarabashh</code></a></li>
<li>Ronen Amiel</li>
</ul>
<p>You can read about our <a
href="https://main--typescript-eslint.netlify.app/users/versioning">versioning
strategy</a> and <a
href="https://main--typescript-eslint.netlify.app/users/releases">releases</a>
on our website.</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/CHANGELOG.md"><code>@typescript-eslint/eslint-plugin</code>'s
changelog</a>.</em></p>
<blockquote>
<h2>8.30.1 (2025-04-14)</h2>
<h3>🩹 Fixes</h3>
<ul>
<li><strong>eslint-plugin:</strong> fix mistake with eslintrc config
generation (<a
href="https://redirect.github.com/typescript-eslint/typescript-eslint/pull/11072">#11072</a>)</li>
</ul>
<h3>❤️ Thank You</h3>
<ul>
<li>Kirk Waiblinger <a
href="https://github.com/kirkwaiblinger"><code>@kirkwaiblinger</code></a></li>
</ul>
<p>You can read about our <a
href="https://main--typescript-eslint.netlify.app/users/versioning">versioning
strategy</a> and <a
href="https://main--typescript-eslint.netlify.app/users/releases">releases</a>
on our website.</p>
<h2>8.30.0 (2025-04-14)</h2>
<h3>🚀 Features</h3>
<ul>
<li><strong>eslint-plugin:</strong> [no-explicit-any] suggest to replace
keyof any with PropertyKey (<a
href="https://redirect.github.com/typescript-eslint/typescript-eslint/pull/11032">#11032</a>)</li>
</ul>
<h3>🩹 Fixes</h3>
<ul>
<li><strong>eslint-plugin:</strong> [promise-function-async] use a
different error message for functions with promise and non-promise types
(<a
href="https://redirect.github.com/typescript-eslint/typescript-eslint/pull/10950">#10950</a>)</li>
</ul>
<h3>❤️ Thank You</h3>
<ul>
<li>Dima Barabash <a
href="https://github.com/dbarabashh"><code>@dbarabashh</code></a></li>
<li>Ronen Amiel</li>
</ul>
<p>You can read about our <a
href="https://main--typescript-eslint.netlify.app/users/versioning">versioning
strategy</a> and <a
href="https://main--typescript-eslint.netlify.app/users/releases">releases</a>
on our website.</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="9531492c70"><code>9531492</code></a>
chore(release): publish 8.30.1</li>
<li><a
href="152def7dba"><code>152def7</code></a>
fix(eslint-plugin): fix mistake with eslintrc config generation (<a
href="https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/eslint-plugin/issues/11072">#11072</a>)</li>
<li><a
href="b3688be33b"><code>b3688be</code></a>
chore(release): publish 8.30.0</li>
<li><a
href="3ccd79c0a5"><code>3ccd79c</code></a>
feat(eslint-plugin): [no-explicit-any] suggest to replace keyof any with
Prop...</li>
<li><a
href="128d95b5da"><code>128d95b</code></a>
fix(eslint-plugin): [promise-function-async] use a different error
message fo...</li>
<li><a
href="69e2f6c0d3"><code>69e2f6c</code></a>
feat: support stringly-typed extends (<a
href="https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/eslint-plugin/issues/10973">#10973</a>)</li>
<li>See full diff in <a
href="https://github.com/typescript-eslint/typescript-eslint/commits/v8.30.1/packages/eslint-plugin">compare
view</a></li>
</ul>
</details>
<br />
Updates `ts-jest` from 29.3.1 to 29.3.2
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/kulshekhar/ts-jest/releases">ts-jest's
releases</a>.</em></p>
<blockquote>
<h2>v29.3.2</h2>
<p>Please refer to <a
href="https://github.com/kulshekhar/ts-jest/blob/main/CHANGELOG.md">CHANGELOG.md</a>
for details.</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/kulshekhar/ts-jest/blob/main/CHANGELOG.md">ts-jest's
changelog</a>.</em></p>
<blockquote>
<h2><a
href="https://github.com/kulshekhar/ts-jest/compare/v29.3.1...v29.3.2">29.3.2</a>
(2025-04-12)</h2>
<h3>Bug Fixes</h3>
<ul>
<li>fix: transpile <code>js</code> files from <code>node_modules</code>
whenever Jest asks (<a
href="https://github.com/kulshekhar/ts-jest/commit/968370e">968370e</a>),
closes <a
href="https://redirect.github.com/kulshekhar/ts-jest/issues/4637">#4637</a></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="e1c6017171"><code>e1c6017</code></a>
chore(release): 29.3.2</li>
<li><a
href="968370e6ef"><code>968370e</code></a>
fix: transpile <code>js</code> files from <code>node_modules</code>
whenever Jest asks (<a
href="https://redirect.github.com/kulshekhar/ts-jest/issues/4791">#4791</a>)</li>
<li><a
href="ddfd81287a"><code>ddfd812</code></a>
build(deps): Update dependency lint-staged to ^15.5.1</li>
<li><a
href="efd5274bf6"><code>efd5274</code></a>
build: use faster mode to build/serve doc</li>
<li><a
href="ccd9a0e798"><code>ccd9a0e</code></a>
build: fix npm audit issue for <code>website</code></li>
<li><a
href="7e730d3056"><code>7e730d3</code></a>
docs: add Hybrid Node module doc about <code>Node16/NodeNext</code></li>
<li><a
href="39a1222326"><code>39a1222</code></a>
test: add dynamic import code test for
<code>transpile-module</code></li>
<li><a
href="5a21aca63a"><code>5a21aca</code></a>
build(deps): Update dependency eslint-config-prettier to ^10.1.2</li>
<li><a
href="e10053f4f5"><code>e10053f</code></a>
build(deps): Update dependency vite to ^6.2.6</li>
<li><a
href="a83170c492"><code>a83170c</code></a>
build(deps): Update ESLint packages to ^8.29.1</li>
<li>Additional commits viewable in <a
href="https://github.com/kulshekhar/ts-jest/compare/v29.3.1...v29.3.2">compare
view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the gradle group with 1 update in the
/.github/workflow-samples/java-toolchain directory:
org.gradle.toolchains.foojay-resolver-convention.
Bumps the gradle group with 1 update in the
/.github/workflow-samples/kotlin-dsl directory:
[com.google.guava:guava](https://github.com/google/guava).
Updates `org.gradle.toolchains.foojay-resolver-convention` from 0.9.0 to
0.10.0
Updates `com.google.guava:guava` from 33.4.6-jre to 33.4.8-jre
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/google/guava/releases">com.google.guava:guava's
releases</a>.</em></p>
<blockquote>
<h2>33.4.8</h2>
<p>Guava 33.4.8 fixes a problem that we introduced while starting to
migrate <code>guava-android</code> off <code>Unsafe</code> in <a
href="https://github.com/google/guava/releases/tag/v33.4.7">33.4.7</a>.</p>
<p>Even if you're not upgrading from Guava 33.4.0 or earlier, still read
<a href="https://github.com/google/guava/releases/tag/v33.4.1">the
release notes for Guava 33.4.1</a>. Those release notes contain
information about the effects of Guava 33.4.5 and higher on the module
system.</p>
<h3>Maven</h3>
<pre lang="xml"><code><dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>33.4.8-jre</version>
<!-- or, for Android: -->
<version>33.4.8-android</version>
</dependency>
</code></pre>
<h3>Jar files</h3>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/33.4.8-jre/guava-33.4.8-jre.jar">33.4.8-jre.jar</a></li>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/33.4.8-android/guava-33.4.8-android.jar">33.4.8-android.jar</a></li>
</ul>
<p>Guava requires <a
href="https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies">one
runtime dependency</a>, which you can download here:</p>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/failureaccess/1.0.3/failureaccess-1.0.3.jar">failureaccess-1.0.3.jar</a></li>
</ul>
<h3>Javadoc</h3>
<ul>
<li><a
href="https://guava.dev/releases/33.4.8-jre/api/docs/">33.4.8-jre</a></li>
<li><a
href="https://guava.dev/releases/33.4.8-android/api/docs/">33.4.8-android</a></li>
</ul>
<h3>JDiff</h3>
<ul>
<li><a
href="https://guava.dev/releases/33.4.8-jre/api/diffs/">33.4.8-jre vs.
33.4.7-jre</a></li>
<li><a
href="https://guava.dev/releases/33.4.8-android/api/diffs/">33.4.8-android
vs. 33.4.7-android</a></li>
<li><a
href="https://guava.dev/releases/33.4.8-android/api/androiddiffs/">33.4.8-android
vs. 33.4.8-jre</a></li>
</ul>
<h3>Changelog</h3>
<ul>
<li><code>util.concurrent</code>: Removed our <code>VarHandle</code>
code from <code>guava-android</code>. While the code was never used at
runtime under Android, it was causing <a
href="https://redirect.github.com/google/guava/issues/7769">problems
under the Android Gradle Plugin</a> with a <code>minSdkVersion</code>
below 26. To continue to avoid <code>sun.misc.Unsafe</code> under the
JVM, <code>guava-android</code> will now always use
<code>AtomicReferenceFieldUpdater</code> when run there.
(75da92419a)</li>
</ul>
<h2>33.4.7</h2>
<p><strong>Prefer to upgrade straight to <a
href="https://github.com/google/guava/releases/tag/v33.4.8">33.4.8</a>:</strong>
33.4.7 <a
href="https://redirect.github.com/google/guava/issues/7769">breaks the
build of Android apps with a minSdkVersion below 26</a>. We will publish
a fixed version soon. This problem is fixed in 33.4.8.</p>
<p>Guava 33.4.7, like <a
href="https://github.com/google/guava/releases/tag/v33.4.6">33.4.6</a>,
fixes two problems that we introduced while modularizing Guava and
migrating off <code>Unsafe</code> in <a
href="https://github.com/google/guava/releases/tag/v33.4.5">33.4.5</a>.</p>
<p>Even if you're not upgrading from Guava 33.4.0 or earlier, still read
<a href="https://github.com/google/guava/releases/tag/v33.4.1">the
release notes for Guava 33.4.1</a>. Those release notes contain
information about the effects of Guava 33.4.5 and higher on the module
system.</p>
<h3>Maven</h3>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/google/guava/commits">compare view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the npm-dependencies group in /sources with 2 updates:
[@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node)
and [typescript](https://github.com/microsoft/TypeScript).
Updates `@types/node` from 20.17.28 to 20.17.30
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node">compare
view</a></li>
</ul>
</details>
<br />
Updates `typescript` from 5.8.2 to 5.8.3
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/microsoft/TypeScript/releases">typescript's
releases</a>.</em></p>
<blockquote>
<h2>TypeScript 5.8.3</h2>
<p>For release notes, check out the <a
href="https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/">release
announcement</a>.</p>
<ul>
<li><a
href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.8.0%22+is%3Aclosed+">fixed
issues query for Typescript 5.8.0 (Beta)</a>.</li>
<li><a
href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.8.1%22+is%3Aclosed+">fixed
issues query for Typescript 5.8.1 (RC)</a>.</li>
<li><a
href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.8.2%22+is%3Aclosed+">fixed
issues query for Typescript 5.8.2 (Stable)</a>.</li>
<li><a
href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.8.3%22+is%3Aclosed+">fixed
issues query for Typescript 5.8.3 (Stable)</a>.</li>
</ul>
<p>Downloads are available on:</p>
<ul>
<li><a href="https://www.npmjs.com/package/typescript">npm</a></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="83dc0bb2ed"><code>83dc0bb</code></a>
Convert release publishing inputs into parameters (<a
href="https://redirect.github.com/microsoft/TypeScript/issues/61523">#61523</a>)</li>
<li><a
href="ba663f6ac2"><code>ba663f6</code></a>
Exclude completions of binding pattern variable initializers (<a
href="https://redirect.github.com/microsoft/TypeScript/issues/52723">#52723</a>)</li>
<li><a
href="7205eda454"><code>7205eda</code></a>
Bump github/codeql-action from 3.28.12 to 3.28.13 in the github-actions
group...</li>
<li><a
href="89c572ca0c"><code>89c572c</code></a>
Fixed a symbol display crash on expando members write locations (<a
href="https://redirect.github.com/microsoft/TypeScript/issues/55478">#55478</a>)</li>
<li><a
href="7b26d2eba5"><code>7b26d2e</code></a>
Fix incorrect name in new release pipeline (<a
href="https://redirect.github.com/microsoft/TypeScript/issues/61514">#61514</a>)</li>
<li><a
href="c7a559eeae"><code>c7a559e</code></a>
Add new release publisher yaml (<a
href="https://redirect.github.com/microsoft/TypeScript/issues/61491">#61491</a>)</li>
<li><a
href="29e6d6689d"><code>29e6d66</code></a>
Fix <code>lib.includes('dom')</code> check in
<code>containerSeemsToBeEmptyDomElement</code> (<a
href="https://redirect.github.com/microsoft/TypeScript/issues/61481">#61481</a>)</li>
<li><a
href="19b777260b"><code>19b7772</code></a>
Bump the github-actions group with 4 updates (<a
href="https://redirect.github.com/microsoft/TypeScript/issues/61474">#61474</a>)</li>
<li><a
href="4dc677b292"><code>4dc677b</code></a>
Fix errors on type assertions in erasableSyntaxOnly (<a
href="https://redirect.github.com/microsoft/TypeScript/issues/61452">#61452</a>)</li>
<li><a
href="ee3dd7264b"><code>ee3dd72</code></a>
fix(60908): Unexpected "'Type' is declared but its value is never
read." erro...</li>
<li>Additional commits viewable in <a
href="https://github.com/microsoft/TypeScript/compare/v5.8.2...v5.8.3">compare
view</a></li>
</ul>
</details>
<br />
<details>
<summary>Most Recent Ignore Conditions Applied to This Pull
Request</summary>
| Dependency Name | Ignore Conditions |
| --- | --- |
| @types/node | [>= 22.a, < 23] |
</details>
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the github-actions group with 2 updates in the / directory:
[tj-actions/changed-files](https://github.com/tj-actions/changed-files)
and [github/codeql-action](https://github.com/github/codeql-action).
Updates `tj-actions/changed-files` from 46.0.3 to 46.0.4
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/tj-actions/changed-files/releases">tj-actions/changed-files's
releases</a>.</em></p>
<blockquote>
<h2>v46.0.4</h2>
<h2>What's Changed</h2>
<ul>
<li>Upgraded to v46.0.3 by <a
href="https://github.com/github-actions"><code>@github-actions</code></a>
in <a
href="https://redirect.github.com/tj-actions/changed-files/pull/2506">tj-actions/changed-files#2506</a></li>
<li>docs: update readme by <a
href="https://github.com/jackton1"><code>@jackton1</code></a> in <a
href="https://redirect.github.com/tj-actions/changed-files/pull/2508">tj-actions/changed-files#2508</a></li>
<li>fix: bug modified_keys and changed_key outputs not set when no
changes detected by <a
href="https://github.com/jackton1"><code>@jackton1</code></a> in <a
href="https://redirect.github.com/tj-actions/changed-files/pull/2509">tj-actions/changed-files#2509</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/tj-actions/changed-files/compare/v46...v46.0.4">https://github.com/tj-actions/changed-files/compare/v46...v46.0.4</a></p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/tj-actions/changed-files/blob/main/HISTORY.md">tj-actions/changed-files's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<h1><a
href="https://github.com/tj-actions/changed-files/compare/v46.0.3...v46.0.4">46.0.4</a>
- (2025-04-03)</h1>
<h2><!-- raw HTML omitted -->🐛 Bug Fixes</h2>
<ul>
<li>Bug modified_keys and changed_key outputs not set when no changes
detected (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2509">#2509</a>)
(<a
href="6cb76d07be">6cb76d0</a>)
- (Tonye Jack)</li>
</ul>
<h2><!-- raw HTML omitted -->📚 Documentation</h2>
<ul>
<li>Update readme (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2508">#2508</a>)
(<a
href="b74df86ccb">b74df86</a>)
- (Tonye Jack)</li>
</ul>
<h2><!-- raw HTML omitted -->⬆️ Upgrades</h2>
<ul>
<li>Upgraded to v46.0.3 (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2506">#2506</a>)</li>
</ul>
<p>Co-authored-by: github-actions[bot] <!-- raw HTML omitted -->
Co-authored-by: Tonye Jack <a
href="mailto:jtonye@ymail.com">jtonye@ymail.com</a> (<a
href="27ae6b33ea">27ae6b3</a>)
- (github-actions[bot])</p>
<h1><a
href="https://github.com/tj-actions/changed-files/compare/v46.0.2...v46.0.3">46.0.3</a>
- (2025-03-23)</h1>
<h2><!-- raw HTML omitted -->🔄 Update</h2>
<ul>
<li>Updated README.md (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2501">#2501</a>)</li>
</ul>
<p>Co-authored-by: github-actions[bot] <!-- raw HTML omitted --> (<a
href="41e0de576a">41e0de5</a>)
- (github-actions[bot])</p>
<ul>
<li>Updated README.md (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2499">#2499</a>)</li>
</ul>
<p>Co-authored-by: github-actions[bot] <!-- raw HTML omitted --> (<a
href="945787811a">9457878</a>)
- (github-actions[bot])</p>
<h2><!-- raw HTML omitted -->📚 Documentation</h2>
<ul>
<li>Remove warning (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2504">#2504</a>)
(<a
href="8132356842">8132356</a>)
- (Tonye Jack)</li>
</ul>
<h2><!-- raw HTML omitted -->⚙️ Miscellaneous Tasks</h2>
<ul>
<li><strong>deps:</strong> Bump test/demo from <code>5dfac2e</code> to
<code>c6bd3b3</code> (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2505">#2505</a>)
(<a
href="823fcebdb3">823fceb</a>)
- (dependabot[bot])</li>
<li>Pin github actions (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2503">#2503</a>)
(<a
href="7a369a7175">7a369a7</a>)
- (Tonye Jack)</li>
<li><strong>deps-dev:</strong> Bump <code>@types/node</code> from
22.13.10 to 22.13.11 (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2502">#2502</a>)
(<a
href="9468856c22">9468856</a>)
- (dependabot[bot])</li>
</ul>
<h2><!-- raw HTML omitted -->⬆️ Upgrades</h2>
<ul>
<li>Upgraded to v46.0.2 (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2500">#2500</a>)</li>
</ul>
<p>Co-authored-by: github-actions[bot] <!-- raw HTML omitted -->
Co-authored-by: Tonye Jack <a
href="mailto:jtonye@ymail.com">jtonye@ymail.com</a> (<a
href="401c7227d1">401c722</a>)
- (github-actions[bot])</p>
<h1><a
href="https://github.com/tj-actions/changed-files/compare/v46.0.1...v46.0.2">46.0.2</a>
- (2025-03-22)</h1>
<h2><!-- raw HTML omitted -->🐛 Bug Fixes</h2>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="6cb76d07be"><code>6cb76d0</code></a>
fix: bug modified_keys and changed_key outputs not set when no changes
detect...</li>
<li><a
href="b74df86ccb"><code>b74df86</code></a>
docs: update readme (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2508">#2508</a>)</li>
<li><a
href="27ae6b33ea"><code>27ae6b3</code></a>
Upgraded to v46.0.3 (<a
href="https://redirect.github.com/tj-actions/changed-files/issues/2506">#2506</a>)</li>
<li>See full diff in <a
href="823fcebdb3...6cb76d07be">compare
view</a></li>
</ul>
</details>
<br />
Updates `github/codeql-action` from 3.28.13 to 3.28.15
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/github/codeql-action/releases">github/codeql-action's
releases</a>.</em></p>
<blockquote>
<h2>v3.28.15</h2>
<h1>CodeQL Action Changelog</h1>
<p>See the <a
href="https://github.com/github/codeql-action/releases">releases
page</a> for the relevant changes to the CodeQL CLI and language
packs.</p>
<h2>3.28.15 - 07 Apr 2025</h2>
<ul>
<li>Fix bug where the action would fail if it tried to produce a debug
artifact with more than 65535 files. <a
href="https://redirect.github.com/github/codeql-action/pull/2842">#2842</a></li>
</ul>
<p>See the full <a
href="https://github.com/github/codeql-action/blob/v3.28.15/CHANGELOG.md">CHANGELOG.md</a>
for more information.</p>
<h2>v3.28.14</h2>
<h1>CodeQL Action Changelog</h1>
<p>See the <a
href="https://github.com/github/codeql-action/releases">releases
page</a> for the relevant changes to the CodeQL CLI and language
packs.</p>
<h2>3.28.14 - 07 Apr 2025</h2>
<ul>
<li>Update default CodeQL bundle version to 2.21.0. <a
href="https://redirect.github.com/github/codeql-action/pull/2838">#2838</a></li>
</ul>
<p>See the full <a
href="https://github.com/github/codeql-action/blob/v3.28.14/CHANGELOG.md">CHANGELOG.md</a>
for more information.</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/github/codeql-action/blob/main/CHANGELOG.md">github/codeql-action's
changelog</a>.</em></p>
<blockquote>
<h1>CodeQL Action Changelog</h1>
<p>See the <a
href="https://github.com/github/codeql-action/releases">releases
page</a> for the relevant changes to the CodeQL CLI and language
packs.</p>
<h2>[UNRELEASED]</h2>
<p>No user facing changes.</p>
<h2>3.28.15 - 07 Apr 2025</h2>
<ul>
<li>Fix bug where the action would fail if it tried to produce a debug
artifact with more than 65535 files. <a
href="https://redirect.github.com/github/codeql-action/pull/2842">#2842</a></li>
</ul>
<h2>3.28.14 - 07 Apr 2025</h2>
<ul>
<li>Update default CodeQL bundle version to 2.21.0. <a
href="https://redirect.github.com/github/codeql-action/pull/2838">#2838</a></li>
</ul>
<h2>3.28.13 - 24 Mar 2025</h2>
<p>No user facing changes.</p>
<h2>3.28.12 - 19 Mar 2025</h2>
<ul>
<li>Dependency caching should now cache more dependencies for Java
<code>build-mode: none</code> extractions. This should speed up
workflows and avoid inconsistent alerts in some cases.</li>
<li>Update default CodeQL bundle version to 2.20.7. <a
href="https://redirect.github.com/github/codeql-action/pull/2810">#2810</a></li>
</ul>
<h2>3.28.11 - 07 Mar 2025</h2>
<ul>
<li>Update default CodeQL bundle version to 2.20.6. <a
href="https://redirect.github.com/github/codeql-action/pull/2793">#2793</a></li>
</ul>
<h2>3.28.10 - 21 Feb 2025</h2>
<ul>
<li>Update default CodeQL bundle version to 2.20.5. <a
href="https://redirect.github.com/github/codeql-action/pull/2772">#2772</a></li>
<li>Address an issue where the CodeQL Bundle would occasionally fail to
decompress on macOS. <a
href="https://redirect.github.com/github/codeql-action/pull/2768">#2768</a></li>
</ul>
<h2>3.28.9 - 07 Feb 2025</h2>
<ul>
<li>Update default CodeQL bundle version to 2.20.4. <a
href="https://redirect.github.com/github/codeql-action/pull/2753">#2753</a></li>
</ul>
<h2>3.28.8 - 29 Jan 2025</h2>
<ul>
<li>Enable support for Kotlin 2.1.10 when running with CodeQL CLI
v2.20.3. <a
href="https://redirect.github.com/github/codeql-action/pull/2744">#2744</a></li>
</ul>
<h2>3.28.7 - 29 Jan 2025</h2>
<p>No user facing changes.</p>
<h2>3.28.6 - 27 Jan 2025</h2>
<ul>
<li>Re-enable debug artifact upload for CLI versions 2.20.3 or greater.
<a
href="https://redirect.github.com/github/codeql-action/pull/2726">#2726</a></li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="45775bd823"><code>45775bd</code></a>
Merge pull request <a
href="https://redirect.github.com/github/codeql-action/issues/2854">#2854</a>
from github/update-v3.28.15-a35ae8c38</li>
<li><a
href="dd78aab407"><code>dd78aab</code></a>
Update CHANGELOG.md with bug fix details</li>
<li><a
href="e40af59174"><code>e40af59</code></a>
Update changelog for v3.28.15</li>
<li><a
href="a35ae8c380"><code>a35ae8c</code></a>
Merge pull request <a
href="https://redirect.github.com/github/codeql-action/issues/2843">#2843</a>
from github/cklin/diff-informed-compat</li>
<li><a
href="bb59df6c17"><code>bb59df6</code></a>
Merge pull request <a
href="https://redirect.github.com/github/codeql-action/issues/2842">#2842</a>
from github/henrymercer/zip64</li>
<li><a
href="4b508f5964"><code>4b508f5</code></a>
Merge pull request <a
href="https://redirect.github.com/github/codeql-action/issues/2845">#2845</a>
from github/mergeback/v3.28.14-to-main-fc7e4a0f</li>
<li><a
href="ca00afb5f1"><code>ca00afb</code></a>
Update checked-in dependencies</li>
<li><a
href="2969c78ce0"><code>2969c78</code></a>
Update changelog and version after v3.28.14</li>
<li><a
href="fc7e4a0fa0"><code>fc7e4a0</code></a>
Merge pull request <a
href="https://redirect.github.com/github/codeql-action/issues/2844">#2844</a>
from github/update-v3.28.14-362ef4ce2</li>
<li><a
href="be0175c800"><code>be0175c</code></a>
Update changelog for v3.28.14</li>
<li>Additional commits viewable in <a
href="1b549b9259...45775bd823">compare
view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the gradle group with 1 update in the
/.github/workflow-samples/groovy-dsl directory:
com.gradle.common-custom-user-data-gradle-plugin.
Bumps the gradle group with 1 update in the
/.github/workflow-samples/kotlin-dsl directory:
com.gradle.common-custom-user-data-gradle-plugin.
Bumps the gradle group with 2 updates in the /sources/test/init-scripts
directory: com.gradle.common-custom-user-data-gradle-plugin and
[com.fasterxml.jackson.dataformat:jackson-dataformat-smile](https://github.com/FasterXML/jackson-dataformats-binary).
Updates `com.gradle.common-custom-user-data-gradle-plugin` from 2.1 to
2.2.1
Updates `com.gradle.common-custom-user-data-gradle-plugin` from 2.1 to
2.2.1
Updates `com.gradle.common-custom-user-data-gradle-plugin` from 2.1 to
2.2.1
Updates `com.fasterxml.jackson.dataformat:jackson-dataformat-smile` from
2.18.2 to 2.18.3
<details>
<summary>Commits</summary>
<ul>
<li><a
href="acc383b238"><code>acc383b</code></a>
[maven-release-plugin] prepare release
jackson-dataformats-binary-2.18.3</li>
<li><a
href="5184301b79"><code>5184301</code></a>
Prep for 2.18.3</li>
<li><a
href="a390dde5ff"><code>a390dde</code></a>
Fix release notes</li>
<li><a
href="2576b3901c"><code>2576b39</code></a>
Merge branch '2.17' into 2.18</li>
<li><a
href="509c39c497"><code>509c39c</code></a>
Add release notes for <a
href="https://redirect.github.com/FasterXML/jackson-dataformats-binary/issues/541">#541</a></li>
<li><a
href="aae1b3714a"><code>aae1b37</code></a>
SmileParser getValueAsString() issue with JsonToken.FIELD_NAME (<a
href="https://redirect.github.com/FasterXML/jackson-dataformats-binary/issues/540">#540</a>)</li>
<li><a
href="b7a257507d"><code>b7a2575</code></a>
Move test for <a
href="https://redirect.github.com/FasterXML/jackson-dataformats-binary/issues/75">#75</a>
from failing to non-failing</li>
<li><a
href="de5efeef12"><code>de5efee</code></a>
Back to snapshot deps</li>
<li><a
href="1f27842342"><code>1f27842</code></a>
[maven-release-plugin] prepare for next development iteration</li>
<li>See full diff in <a
href="https://github.com/FasterXML/jackson-dataformats-binary/compare/jackson-dataformats-binary-2.18.2...jackson-dataformats-binary-2.18.3">compare
view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Bumps the npm-dependencies group in /sources with 2 updates:
[@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node)
and [ts-jest](https://github.com/kulshekhar/ts-jest).
Updates `@types/node` from 20.17.27 to 20.17.28
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node">compare
view</a></li>
</ul>
</details>
<br />
Updates `ts-jest` from 29.3.0 to 29.3.1
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/kulshekhar/ts-jest/releases">ts-jest's
releases</a>.</em></p>
<blockquote>
<h2>v29.3.1</h2>
<p>Please refer to <a
href="https://github.com/kulshekhar/ts-jest/blob/main/CHANGELOG.md">CHANGELOG.md</a>
for details.</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/kulshekhar/ts-jest/blob/main/CHANGELOG.md">ts-jest's
changelog</a>.</em></p>
<blockquote>
<h2><a
href="https://github.com/kulshekhar/ts-jest/compare/v29.3.0...v29.3.1">29.3.1</a>
(2025-03-31)</h2>
<h3>Bug Fixes</h3>
<ul>
<li>fix: allow <code>isolatedModules</code> mode to have
<code>ts.Program</code> under <code>Node16/Next</code> (<a
href="https://github.com/kulshekhar/ts-jest/commit/25157eb">25157eb</a>)</li>
<li>fix: improve message for <code>isolatedModules</code> of
<code>ts-jest</code> config (<a
href="https://github.com/kulshekhar/ts-jest/commit/547eb6f">547eb6f</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="7738269b23"><code>7738269</code></a>
chore(release): 29.3.1</li>
<li><a
href="04a12d73ab"><code>04a12d7</code></a>
test: improve <code>examples</code> folder</li>
<li><a
href="547eb6f811"><code>547eb6f</code></a>
fix: improve message for <code>isolatedModules</code> of
<code>ts-jest</code> config</li>
<li><a
href="0c3465fe26"><code>0c3465f</code></a>
docs: indicate clearer about <code>isolatedModules</code>
deprecation</li>
<li><a
href="25157eb124"><code>25157eb</code></a>
fix: allow <code>isolatedModules</code> mode to have Program under
<code>Node16/Next</code></li>
<li><a
href="cc1f630b98"><code>cc1f630</code></a>
build(deps): Update dependency <code>@types/node</code> to
v20.17.28</li>
<li><a
href="66bde83d25"><code>66bde83</code></a>
build(deps): Update dependency <code>@types/semver</code> to
^7.7.0</li>
<li><a
href="a4275caf18"><code>a4275ca</code></a>
Remove --no-audit</li>
<li><a
href="38cacd360d"><code>38cacd3</code></a>
Add NPM cache</li>
<li><a
href="36e3883310"><code>36e3883</code></a>
build(deps): Update dependency <code>@formatjs/ts-transformer</code> to
^3.13.34</li>
<li>Additional commits viewable in <a
href="https://github.com/kulshekhar/ts-jest/compare/v29.3.0...v29.3.1">compare
view</a></li>
</ul>
</details>
<br />
<details>
<summary>Most Recent Ignore Conditions Applied to This Pull
Request</summary>
| Dependency Name | Ignore Conditions |
| --- | --- |
| @types/node | [>= 22.a, < 23] |
</details>
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the gradle group with 1 update in the /.github/workflow-samples/groovy-dsl directory: com.gradle.common-custom-user-data-gradle-plugin.
Bumps the gradle group with 1 update in the /.github/workflow-samples/kotlin-dsl directory: com.gradle.common-custom-user-data-gradle-plugin.
Bumps the gradle group with 2 updates in the /sources/test/init-scripts directory: com.gradle.common-custom-user-data-gradle-plugin and [com.fasterxml.jackson.dataformat:jackson-dataformat-smile](https://github.com/FasterXML/jackson-dataformats-binary).
Updates `com.gradle.common-custom-user-data-gradle-plugin` from 2.1 to 2.2.1
Updates `com.gradle.common-custom-user-data-gradle-plugin` from 2.1 to 2.2.1
Updates `com.gradle.common-custom-user-data-gradle-plugin` from 2.1 to 2.2.1
Updates `com.fasterxml.jackson.dataformat:jackson-dataformat-smile` from 2.18.2 to 2.18.3
- [Commits](https://github.com/FasterXML/jackson-dataformats-binary/compare/jackson-dataformats-binary-2.18.2...jackson-dataformats-binary-2.18.3)
---
updated-dependencies:
- dependency-name: com.gradle.common-custom-user-data-gradle-plugin
dependency-version: 2.2.1
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: gradle
- dependency-name: com.gradle.common-custom-user-data-gradle-plugin
dependency-version: 2.2.1
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: gradle
- dependency-name: com.gradle.common-custom-user-data-gradle-plugin
dependency-version: 2.2.1
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: gradle
- dependency-name: com.fasterxml.jackson.dataformat:jackson-dataformat-smile
dependency-version: 2.18.3
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: gradle
...
Signed-off-by: dependabot[bot] <support@github.com>
Bumps the gradle group with 1 update in the
/.github/workflow-samples/kotlin-dsl directory:
[com.google.guava:guava](https://github.com/google/guava).
Updates `com.google.guava:guava` from 33.4.5-jre to 33.4.6-jre
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/google/guava/releases">com.google.guava:guava's
releases</a>.</em></p>
<blockquote>
<h2>33.4.6</h2>
<p>Guava 33.4.6 fixes two problems that we introduced while modularizing
Guava in <a
href="https://github.com/google/guava/releases/tag/v33.4.5">33.4.5</a>.</p>
<p>Even if you're not upgrading from Guava 33.4.0 or earlier, still read
<a href="https://github.com/google/guava/releases/tag/v33.4.1">the
release notes for Guava 33.4.1</a>. Those release notes contain
information about Guava 33.4.5 and 33.4.6's effect on the module
system.</p>
<h3>Maven</h3>
<pre lang="xml"><code><dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>33.4.6-jre</version>
<!-- or, for Android: -->
<version>33.4.6-android</version>
</dependency>
</code></pre>
<h3>Jar files</h3>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/33.4.6-jre/guava-33.4.6-jre.jar">33.4.6-jre.jar</a></li>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/33.4.6-android/guava-33.4.6-android.jar">33.4.6-android.jar</a></li>
</ul>
<p>Guava requires <a
href="https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies">one
runtime dependency</a>, which you can download here:</p>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/failureaccess/1.0.3/failureaccess-1.0.3.jar">failureaccess-1.0.3.jar</a></li>
</ul>
<h3>Javadoc</h3>
<ul>
<li><a
href="https://guava.dev/releases/33.4.6-jre/api/docs/">33.4.6-jre</a></li>
<li><a
href="https://guava.dev/releases/33.4.6-android/api/docs/">33.4.6-android</a></li>
</ul>
<h3>JDiff</h3>
<ul>
<li><a
href="https://guava.dev/releases/33.4.6-jre/api/diffs/">33.4.6-jre vs.
33.4.5-jre</a></li>
<li><a
href="https://guava.dev/releases/33.4.6-android/api/diffs/">33.4.6-android
vs. 33.4.5-android</a></li>
<li><a
href="https://guava.dev/releases/33.4.6-android/api/androiddiffs/">33.4.6-android
vs. 33.4.6-jre</a></li>
</ul>
<h3>Changelog</h3>
<ul>
<li>Removed the extra copy of each class from the Guava jar. The extra
copies were an accidental addition from the modularization work in <a
href="https://github.com/google/guava/releases/tag/v33.4.5">Guava
33.4.5</a>. (40485b93ce)</li>
<li>Fixed annotation-related warnings when using Guava in modular
builds. The most common such warning is <code>Cannot find annotation
method 'value()' in type 'DoNotMock': ...</code>. (7e15ab3566)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/google/guava/commits">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The request for a short lived access token fails if the server
certificate is self signed and `develocity-allow-untrusted-server` is
set to true.
I wasn't sure how to write a test for this since nock does not seem to
support mocking a ssl error response.
By inspecting a greater range of build operations for failure, the Job
summary will correctly reflect the build outcome in more circumstances.
Note that we now use the old 'buildFinished' mechanism for all Gradle
versions < `7.0`, instead of using the BuildService mechanism for all
Gradle versions from `6.6`. This avoids needing to deal with
inconsistent build operations present in Gradle versions `[6.6, 7.0)`.
Fixes#415
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.
Fixes the Groovy syntax in 2 init-scripts to avoid deprecation warnings.
The fix to the DV injection script is temporary, and will be replaced by
a fix in the upstream reference script.
Fixes#541
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.
# Combined PRs ➡️📦⬅️✅ The following pull requests have been successfully combined on this
PR:
- Closes#534 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/kotlin-dsl
- Closes#533 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/java-toolchain
- Closes#532 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/groovy-dsl
- Closes#531 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/gradle-plugin
- Closes#530 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/sources/test/init-scripts
> This PR was created by the
[`github/combine-prs`](https://github.com/github/combine-prs) action
---------
Signed-off-by: bot-githubaction <bot-githubaction@gradle.com>
Co-authored-by: bot-githubaction <bot-githubaction@gradle.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
The cache-cleanup operation works by executing Gradle on a dummy project
and a custom init-script. The version of Gradle used should be at least
as high as the newest version used to run a build.
Previously, if the Gradle version on PATH didn't meet this requirement,
the action would download and install the required Gradle version.
With this PR, the action will now use an existing Gradle wrapper
distribution if it meets the requirement. This avoids unnecessary
downloads of Gradle versions that are already present on the runner.
The logic is:
- Determine the newest version of Gradle that was executed during the
Job. This is the 'minimum version' for cache cleanup.
- Inspect the Gradle version on PATH and any detected wrapper scripts to
see if they meet the 'minimum version'.
- The first executable that is found to meet the requirements will be
used for cache-cleanup.
- If no executable is found that meets the requirements, attempt to
provision Gradle with the 'minimum version'.
Fixes#515
The cache-cleanup operation works by executing Gradle on a dummy project
and a custom init-script. The init-script requires at least Gradle 8.11
to work.
Ideally, the version of Gradle used for cleanup should be no older than
the newest one that wrote entries to Gradle User Home. If an older
Gradle version is used for cache-cleanup, it will not remove entries
written specifically for newer versions.
With this change, we now attempt to ensure that cache-cleanup is run
with the best Gradle version available. We inspect the Gradle version on
PATH to see if it is new enough, otherwise we will provision a Gradle
version equal to the newest one that ran in the Job.
The logic is:
- Determine the newest version of Gradle that was executed during the
Job. This is the 'minimum version' for cache cleanup.
- Inspect the Gradle version on PATH (if any) to see if it is equal to
or newer than the 'minimum version'.
- If the version Gradle on PATH is new enough, use that version for
cache-cleanup.
- If not, attempt to provision Gradle with the 'minimum version'.
Fixes#436
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
The Gradle build used to perform cache-cleanup will run in the context of init-scripts
provided by the action, including those that collect build-results.
In some circumstances this can lead to unexpected results, such as saving configuration-cache
entries for cache cleanup executions.
With this change, build results will not be captured for cache-cleanup builds.
Previously we were relying on Gradle to substitute JDK environment variables
in toolchains.xml. With this change, the actual path to the JDK is encoded instead.
This should avoid issues where Gradle is not able to successfully resolve the
envioronment variable.
# Combined PRs ➡️📦⬅️✅ The following pull requests have been successfully combined on this
PR:
- Closes#498 Bump Gradle Wrapper from 8.11.1 to 8.12 in
/.github/workflow-samples/kotlin-dsl
- Closes#497 Bump Gradle Wrapper from 8.11.1 to 8.12 in
/.github/workflow-samples/java-toolchain
- Closes#496 Bump Gradle Wrapper from 8.11.1 to 8.12 in
/.github/workflow-samples/groovy-dsl
- Closes#495 Bump Gradle Wrapper from 8.11.1 to 8.12 in
/.github/workflow-samples/gradle-plugin
- Closes#494 Bump Gradle Wrapper from 8.11.1 to 8.12 in
/sources/test/init-scripts
> This PR was created by the
[`github/combine-prs`](https://github.com/github/combine-prs) action
---------
Signed-off-by: bot-githubaction <bot-githubaction@gradle.com>
Co-authored-by: bot-githubaction <bot-githubaction@gradle.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: daz <daz@gradle.com>
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: bigdaz <179734+bigdaz@users.noreply.github.com>
Bumps the gradle group with 1 update in the /sources/test/init-scripts
directory:
[com.fasterxml.jackson.dataformat:jackson-dataformat-smile](https://github.com/FasterXML/jackson-dataformats-binary).
Updates `com.fasterxml.jackson.dataformat:jackson-dataformat-smile` from
2.18.1 to 2.18.2
<details>
<summary>Commits</summary>
<ul>
<li><a
href="147bc6024b"><code>147bc60</code></a>
[maven-release-plugin] prepare release
jackson-dataformats-binary-2.18.2</li>
<li><a
href="92648ab980"><code>92648ab</code></a>
Prep for 2.18.2</li>
<li><a
href="d31d695767"><code>d31d695</code></a>
Merge branch '2.17' into 2.18</li>
<li><a
href="a7232c691a"><code>a7232c6</code></a>
Back to snapshot dep</li>
<li><a
href="b362d85402"><code>b362d85</code></a>
[maven-release-plugin] prepare for next development iteration</li>
<li><a
href="d817f53ab6"><code>d817f53</code></a>
[maven-release-plugin] prepare release
jackson-dataformats-binary-2.17.3</li>
<li><a
href="d88c088671"><code>d88c088</code></a>
Prep for 2.17.3</li>
<li><a
href="fa5abd6573"><code>fa5abd6</code></a>
Back to snapshot dep</li>
<li><a
href="d048e2fd91"><code>d048e2f</code></a>
[maven-release-plugin] prepare for next development iteration</li>
<li>See full diff in <a
href="https://github.com/FasterXML/jackson-dataformats-binary/compare/jackson-dataformats-binary-2.18.1...jackson-dataformats-binary-2.18.2">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
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: bigdaz <179734+bigdaz@users.noreply.github.com>
The build-result-capture.init.gradle script was making some assumptions about
extensions and plugin application that do not apply with the newest GE plugin.
Fixes#449
This test was originally starting with an empty set of checksums,
leading to the download of a checksum for every released and snapshot
version. This resulted in in sporadic test failures.
We now start with a known set of checksums and ensure that those that
are missing are downloaded. This involved some refactoring and
improvement in the way snapshot checksums are processed.
Although we run `setup-gradle` with all/most wrapper files, this global
workflow will ensure that all wrapper files in the repo are valid.
(This should help with the OSSF scorecard)
The cache-cleanup API has changed, so the init-script that worked with
Gradle 8.9 no longer works with 8.11.
We now provision and use Gradle 8.11 for cache cleanup.
This provides a band-aid fix for #417 but that issue will still impact
any build configured to run with Gradle > 8.11
This test assumed that at least one 'snapshot' wrapper checksum was unique,
and not contained in the set of wrapper checksums for released distributions.
This is no longer the case, so the assumption has been modified.
Instead of always installing and using the latest Gradle version for
cache cleanup, we now require at least Gradle 8.9.
This avoids downloading and installing Gradle if the version on PATH is
sufficient to perform cache cleanup.
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
- Add deprecation warning for `gradle-home-cache-cleanup`
- Change default for `dependency-submission` to `cache-cleanup: on-success`
- Update documentation for changed default
Previously, including RUNNER_OS was enough to prevent leaking incompatible
content between Gradle User Homes. With the introduction of macos-14,
we now need to differentiate between different runner architectures as well.
Fixes#138
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 checksum values for most wrapper versions are hard-coded into the
action. These known checksum values are first used for validation: only
if none of the known values work do we download checksums.
Previously, we blindly downloaded all of the checksum values in this
case: we now only download the checksums for versions that are not in
our "known" set.
Fixes#171
Gradle 8.8 introduces new features that allow us to avoid using
timestamp manipulation to force the cleanup of the Gradle User Home directory.
This solution is simpler and more robust, but relies on Gradle 8.8+ always being
used for the cache cleanup operation.
Fixes#24
To cleanup Gradle User Home, a Gradle build must be executed.
Newer Gradle versions are able to cleanup the home directories of older versions,
but not vice-versa.
With this change, the latest version of Gradle is automatically provisioned
in order to run Gradle User Home cleanup. This ensures a consistent version of
Gradle is used for cleanup, and fixes#33 where Gradle is not pre-installed on
a custom runner.
- Always fetch a token for every hostname in the access key
- Use any tokens that are successfully fetched
- Retain access key if no tokens can be fetched
Follow up of https://github.com/gradle/actions/pull/224, we now attempt to set both old and new access key env variables to a short lived token.
If a short-lived token cannot be obtained, then:
- DEVELOCITY_ACCESS_KEY is set to an empty string, preventing this from being used.
- GRADLE_ENTERPRISE_ACCESS_KEY is left intact, with a deprecation warning being issued.
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 <daz@gradle.com>
Improve readability of build scan when requested tasks is very long, as
agreed in #175. HTML diff for each case of job summary is clearer in
cd62d9c9efc15c90df77242059b98bdaa4f39a43.
- Ensure a minimum size for the badge, at least the size of "Build
scan®", by preventing a line break with ` `
- Reduce the size of the badge by tweaking the inner text
Also fix a typo in the build shell script.
Deprecation warning will be emitted when we:
- Change 'wrapper-validation-action' to delegate to 'actions/wrapper-validation'
- Add the 'wrapper-validation-action' id as env var before delegating
After the '[bot] update dist directory' commit, we run a full test suite.
This will now use the content from the 'dist' directory, rather than
regenerating this content in the test.
This will permit workflows to run when this commit is applied.
- Avoid running ci-update-dist for modifications to dist directory (no recursion)
- Run full-suite only in response to bot updates.
Adds a 'validate-wrappers' option to `gradle/actions/setup-gradle`,
which defaults to 'false'.
When 'true', the action will first validate all Gradle wrappers in the
repository before proceeding.
Fixes#161
Having a single repository to host all of the Gradle GitHub Actions will
provide numerous benefits:
1. Easier to stay on top of dependency updates
2. More frequent release cycle
3. Enable integration between different actions like automatic wrapper
validation with `setup-gradle`.
Instead of relying on push triggers in general, we now use pull_request
and reserve push triggers for main and release branches.
This makes the behaviour more consistent for users contributing from
repository forks. However, we no longer have a quick-feedback loop
for development.
Different runners have different JDKs installed, so using a hard-coded
list for
`toolchains.xml` doesn't work. With this change, the file is generated
based on the available `JAVA_HOME_*` environment variables.
Fixes#89
Thanks @hfhbd for the contribution!
Co-authored-by: hfhbd <22521688+hfhbd@users.noreply.github.com>
Bumps com.gradle.develocity from 3.17 to 3.17.1.
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps com.gradle.develocity from 3.17 to 3.17.1.
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps com.gradle.develocity from 3.17 to 3.17.1.
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps com.gradle.develocity from 3.17 to 3.17.1.
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Instead of requiring that developers keep the 'dist' directory up-to-date,
this process is now automated via a workflow.
Whenever a commit is pushed to 'main' (or a 'release/**' branch), the workflow will
build the application and commit any changes to the 'dist' directory.
A bunch of improvements to the GHA workflow pipeline including:
- Separate workflow for unit tests
- Always use a locally-built dist directory for integ-tests
- Only run 'quick' integ-tests for non-PR commits. Once a PR is submitted, the 'full' suite will be run on each push.
Without a mechanism to check this in the workflow trigger,
we instead run the workflow but skip all jobs if the commit belongs to a PR.
This effectively means that commits-without-PR will run quick-check, and commits-with-PR
will run full-check.
- Adds an upgrade-guide to assist with resolving deprecations
- Emit a warning when deprecated features are used
- List all deprecated features in Job Summary and link to upgrade guide
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.
- Add `RELEASING.md` to document the release process
- Mention the recommendation to disable local build-cache when remote
build-cache is available. Fixes#102
- All cache keys are now structured as `gradle-<cache-name>-<protocol-version>-<key>`. This ensures that extracted entries are prefixed and versioned consistently
- Avoid using custom cache-key prefix for extracted entries. This should reduce the churn in integration tests that require some level of cache isolation.
As a result of this change, cache entries written with previous versions of the action will not be used.
- All cache keys are now structured as 'gradle-<cache-name>-<protocol-version>
- This ensures that extracted entries are prefixed and versioned consistently
- Avoid using custom cache-key prefix for extracted entries. This should reduce the
churn in integration tests that require some level of cache isolation.
Finishes the migration of `dependency-submission` to a Typescript action
(fixes#116)
- Use consistent input params to ensure behaviour is consistent with
'setup-gradle'
- Submit generated graph immediately instead of waiting until end of job
(fixes#123)
- Can now add a `dependency-submission` step after a `setup-gradle` step
in the same job (fixes#36)
While `setup-gradle` must wait until the end of job to submit all of the generated
graphs, the `dependency-submission` action will not save/upload the generated graph
immediately, in the same step where it is generated.
The original implementation was a thin `composite` wrapper that delegated to `setup-gradle`.
It is now a full-fledged action sharing implementation details.
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.
Instead of being a thin wrapper over `setup-gradle`, the `dependency-submission`
action is now a fully-fledged action sharing implementation with `setup-gradle`.
- Switch to use `com.gradle.develocity` for plugin ID
- Switch to use `v3.17` for plugin version
- Update for change documentation URLs
- Update for changes to `develocity` DSL
To handle the rebranding of the GE plugin, this PR updates the inject-develocity init script
to apply the `com.gradle.develocity` plugin if `3.17+` version of the plugin is requested.
This PR changes the behavior such that task input files are captured
when the environment variable is explicitly specified and for the cases
when the plugin is not applied.
---------
Co-authored-by: Alexis Tual <atual@gradle.com>
The 'resolveAllDependencies' task is incompatible with project isolation.
Pending a fix to the plugin, disable this feature when running the
dependency-submission action.
Fixes#39
Instead of using 'dependency-graph-action' with some slightly better
values, we now use 'dependency-graph' as the parameter name with a subset
of the options available to 'setup-gradle'.
To prepare for converting the 'dependency-submission' action into Typescript,
we move the 'setup-gradle' entry points and outputs into a sub-directory.
This brings the entire codebase and history of `gradle/gradle-build-action` into
the `gradle/actions` repository, after some modifications to make it easier to
merge.
This will permit the new `gradle/actions/setup-gradle` coordinates to carry on
where `gradle/gradle-build-action` leaves off.
- All NPM sources have been moved into a 'sources' directory
- The main action.yml and README are not located at `setup-gradle`
Bumps the github-actions group with 1 update:
[gradle/gradle-build-action](https://github.com/gradle/gradle-build-action).
Updates `gradle/gradle-build-action` from 2.11.1 to 2.12.0
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/gradle/gradle-build-action/releases">gradle/gradle-build-action's
releases</a>.</em></p>
<blockquote>
<h2>v2.12.0</h2>
<p>Adds a new option to clear a previously submitted
dependency-graph.</p>
<pre lang="yaml"><code>steps:
- uses: gradle/gradle-build-action@v2
with:
dependency-graph: clear
</code></pre>
<p>This may prove useful when migrating to a workflow using the upcoming
<code>gradle/actions/dependency-submission</code> action.</p>
<p><strong>Full-changelog</strong>: <a
href="https://github.com/gradle/gradle-build-action/compare/v2.11.1...v2.12.0">https://github.com/gradle/gradle-build-action/compare/v2.11.1...v2.12.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="a8f75513ea"><code>a8f7551</code></a>
Build outputs</li>
<li><a
href="9283312acb"><code>9283312</code></a>
Add new option to clear dependency-graph</li>
<li><a
href="7c8a278ea0"><code>7c8a278</code></a>
Remove old clear-dependency-graph action</li>
<li><a
href="d8ca9b7d2e"><code>d8ca9b7</code></a>
Do full checks on release branches</li>
<li>See full diff in <a
href="https://github.com/gradle/gradle-build-action/compare/v2.11.1...v2.12.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The default JDK on some runners can have minor differences, resulting
in configuration-cache misses. Setting the Java version explicitly should
ensure consistency.
When changing workflow names or when changing to the new 'dependency-submission'
action, it can be useful to clear existing dependency graph snapshots from previous
submissions. While the old graphs will eventually "age out", the 'clear' option will
submit an empty dependency graph for an existing Job correlator, ensuring that old
dependency graphs don't linger.
When using the `@actions/cache` library to save cache entries, it seems that one
or more Promises remain unresolved after the save completes.
With Node20 this causes a delay when exiting the process: the default behaviour
now wait for these Promises to complete. Adding an explicit `Process.exit()`
removes the delay, returning to the Node 16 behaviour.
Fixes#1038
These actions simply delegate to `gradle/gradle-build-action`
- `setup-gradle`: As `gradle-build-action` without the execution capability.
- `dependency-submission`: Submits a dependency graph for the project.
One goal for the original dependency-graph support was to minimize it's
impact on existing workflows, by operating transparently and not
impacting the build outcome. This meant that any failures in
dependency-graph generation or submission were logged as warnings, but
did not cause the workflow to fail.
However, in some cases the primary purpose of a workflow is to generate
and submit a dependency graph: in these cases it is desirable to have
the workflow fail when this process breaks.
This PR introduces a new `dependency-graph-continue-on-failure`
parameter, which when `false` will enable the latter behaviour. It also
adds test coverage for different failures in dependency graph generation
and submission.
Fixes#1034Fixes#997
- Translate to env var for init-script support
- Use when deciding whether to log or rethrow errors
- Add a custom error type to trigger failure in post action
When state is reused from the configuration cache, no dependencies are resolved.
This fix prevents the action from submitting an empty dependency graph in this case.
Since adding these to the `org.gradle.java.installations.fromEnv` property
is problematic (#1024), this mechanism allows the default toolchains to
be discovered by Gradle via a different mechanism.
The default JDK installations are added to `~/.m2/toolchains.xml` such that
they are discoverable by Gradle toolchain support.
The `setup-java` action also writes to this file, so we merge with any existing
content: this allows both pre-installed and "setup" JDKs to be automatically
detected by Gradle.
Previously, the workflow name was always included when matching a cache entry for the current job.
This can be overly restrictive when job definitions are shared between different workflows.
The workflow name is still encoded in the cache entry key, but not in the restore key searching for entries with a matching job.
Fixes#1017
Instead of a binary true/false option, it is now possible to only add
a Job Summary when the build failed. This applies both to the overall
Job Summary added to the workflow run, and to the new PR comment feature.
Rather than requiring a separate step to add a PR comment,
the `gradle-build-action` can now automatically add the Job Summary
as a PR comment
Fixes#1020
- Don't upload artifacts when using 'generate-and-submit'
- New option 'generate-and-upload' to be used with 'download-and-submit'
- Use Artifact API for downloading in the same and different workflow
- Avoid "Entry not saved: reason unknown" when entry was not restored
- Avoid "Entry not saved: Encryption key not provided" when no config-cache data found
- Avoid spurious log message when no config-cache data found
Earlier versions of Gradle didn't support the `GRADLE_ENCRYPTION_KEY`
for the configuration-cache, and so are either not useful to save,
or are actually unsafe due to unencrypted secrets.
We use semver to compare the Gradle version used to produce the config-cache
entry with the minimum Gradle version required.
- Avoid logging "not restoring" message when no entries exist to restore
- Clear the entries from metadata when they are not restored. This ensures that
the non-restored entries are correctly purged.
This makes it easier for users to enable config-cache saving in their workflow.
Config-cache data will only be saved/restored when the key is provided,
and the key is exported as `GRADLE_ENCRYPTION_KEY` for use in subsequent steps.
# This Action will scan dependency manifest files that change as part of a Pull Request, surfacing known-vulnerable versions of the packages declared or updated in the PR. Once installed, if the workflow run is marked as required, PRs introducing known-vulnerable packages will be blocked from merging.
# Public documentation: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#dependency-review-enforcement
# Therefore suggest below to close and then reopen the PR
body:|
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.
The "distribution" for a GitHub Action is checked into the repository itself.
The `build` script in the project root provides a convenient way to perform many local build tasks:
In the case of the `gradle-build-action`, the transpiled sources are committed to the `dist` directory.
1. `./build` will lint and compile typescript sources
Any production dependencies are inlined into the distribution.
2. `./build all` will lint and compile typescript and run unit tests
So if a Dependabot PR updates a production dependency (or a dev dependency that changes the distribution, like the Typescript compiler),
3. `./build install` will install npm packages followed by lint and compile
then a manual step is required to rebuild the dist and commit.
4. `./build init-scripts` will run the init-script integration tests
5. `./build act <act-commands>` will run `act` after building local changes (see below)
The simplest process to follow is:
## Using `act` to run integ-test workflows locally
1. Checkout the dependabot branch locally eg: `git checkout dependabot/npm_and_yarn/actions/github-5.1.0`
2. Run `npm install` to download and the new dependencies and install locally
It's possible to run GitHub Actions workflows locally with https://nektosact.com/.
3. Run `npm run build` to regenerate the distribution
Many of the test workflows from this repository can be run in this way, making it easier to
4. Push the changes to the dependabot branch
test local changes without pushing to a branch.
5. If/when the checks pass, you can merge the dependabot PR
This feature is most useful to run a single `integ-test-*` workflow. Avoid running `ci-quick-test` or other aggregating workflows unless you want to use your local machine as a heater!
- `integ-test-detect-java-toolchains.yml` fails when running on a `linux/amd64` container, since the expected pre-installed JDKs are not present. Should be fixed by #89.
- `act` is not yet compatible with `actions/upload-artifact@v4` (or related toolkit functions)
- See https://github.com/nektos/act/pull/2224
- Workflows run by `act` cannot submit to the dependency-submission API, as no `GITHUB_TOKEN` is available by default.
Tips:
- Add the following lines to `~/.actrc`:
- `--container-daemon-socket -` : Prevents "error while creating mount source path", and yes that's a solitary dash at the end
- `--matrix os:ubuntu-latest` : Avoids a lot of logging about unsupported runners being skipped
- Runners don't have `java` installed by default, so all workflows that run Gradle require a `setup-java` step.
This repository contains a set of GitHub Actions that are useful for building Gradle projects on GitHub.
It is possible to directly invoke Gradle in your workflow, and the `actions/setup-java@v3` action provides a simple way to cache Gradle dependencies.
## The `setup-gradle` action
However, the `gradle-build-action` offers a number of advantages over this approach:
The `setup-gradle` action can be used to configure Gradle for optimal execution on any platform supported by GitHub Actions.
- Easily [configure your workflow to use a specific version of Gradle](#choose-a-specific-gradle-version) using the `gradle-version` parameter. Gradle distributions are automatically downloaded and cached.
This replaces the previous `gradle/gradle-build-action`, which now delegates to this implementation.
- More sophisticated and more efficient caching of Gradle User Home between invocations, compared to `setup-java` and most custom configurations using `actions/cache`. [More details below](#caching-build-state-between-jobs).
- Detailed reporting of cache usage and cache configuration options allow you to [optimize the use of the GitHub actions cache](#optimizing-cache-effectiveness).
- [Generate and Submit a GitHub Dependency Graph](#github-dependency-graph-support) for your project, enabling Dependabot security alerts.
- [Automatic capture of Build Scan® links](#build-reporting) from the build, making these easier to locate for workflow run.
The `gradle-build-action` is designed to provide these benefits with minimal configuration.
The recommended way to execute any Gradle build is with the help of the [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html), and the examples assume that the Gradle Wrapper has been configured for the project. See [this example](docs/setup-gradle.md#build-with-a-specific-gradle-version) if your project doesn't use the Gradle Wrapper.
These features work both when Gradle is executed via the `gradle-build-action` and for any Gradle execution in subsequent steps.
## Use the action to setup Gradle
The recommended way to use the `gradle-build-action` is in an initial "Setup Gradle" step, with subsequent steps invoking Gradle directly with a `run` step. This makes the action minimally invasive, and allows a workflow to configure and execute a Gradle execution in any way.
The `gradle-build-action` works by configuring environment variables and by adding a set of Gradle init-scripts to the Gradle User Home. These will apply to all Gradle executions on the runner, no matter how Gradle is invoked.
This means that if you have an existing workflow that executes Gradle with a `run` step, you can add an initial "Setup Gradle" Step to benefit from caching, build-scan capture and other features of the gradle-build-action.
### Example usage
```yaml
```yaml
name: Run Gradle on PRs
name: Build
on: pull_request
jobs:
gradle:
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v3
with:
distribution: temurin
java-version: 11
- name: Setup Gradle
uses: gradle/gradle-build-action@v2
- name: Execute Gradle build
run: ./gradlew build
```
## Choose a specific Gradle version
The `gradle-build-action` can download and install a specified Gradle version, adding this installed version to the PATH.
Downloaded Gradle versions are stored in the GitHub Actions cache, to avoid requiring downloading again later.
```yaml
- uses: gradle/gradle-build-action@v2
with:
gradle-version: 6.5
```
The `gradle-version` parameter can be set to any valid Gradle version.
Moreover, you can use the following aliases:
| Alias | Selects |
| --- |---|
| `wrapper` | The Gradle wrapper's version (default, useful for matrix builds) |
| `current` | The current [stable release](https://gradle.org/install/) |
| `release-candidate` | The current [release candidate](https://gradle.org/release-candidate/) if any, otherwise fallback to `current` |
| `nightly` | The latest [nightly](https://gradle.org/nightly/), fails if none. |
| `release-nightly` | The latest [release nightly](https://gradle.org/release-nightly/), fails if none. |
This can be handy to automatically verify your build works with the latest release candidate of Gradle:
The actual Gradle version used is available as an action output: `gradle-version`.
```yaml
name: Test latest Gradle RC
on:
schedule:
- cron: 0 0 * * * # daily
jobs:
gradle-rc:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v3
with:
distribution: temurin
java-version: 11
- uses: gradle/gradle-build-action@v2
id: setup-gradle
with:
gradle-version: release-candidate
- run: gradle build --dry-run # just test build configuration
- run: echo "The release-candidate version was ${{ steps.setup-gradle.outputs.gradle-version }}"
```
## Caching build state between Jobs
The `gradle-build-action` will use the GitHub Actions cache to save and restore reusable state that may be speed up a subsequent build invocation. This includes most content that is downloaded from the internet as part of a build, as well as expensive to create content like compiled build scripts, transformed Jar files, etc.
The state that is cached includes:
- Any distributions downloaded to satisfy a `gradle-version` parameter ;
- A subset of the Gradle User Home directory, including downloaded dependencies, wrapper distributions, and the local build cache ;
To reduce the space required for caching, this action makes a best effort to reduce duplication in cache entries.
State will be restored from the cache during the first `gradle-build-action` step for any workflow job, and cache entries will be written back to the cache at the end of the job, after all Gradle executions have completed.
### Disabling caching
Caching is enabled by default. You can disable caching for the action as follows:
```yaml
cache-disabled: true
```
### Using the cache read-only
By default, the `gradle-build-action` will only write to the cache from Jobs on the default (`main`/`master`) branch.
Jobs on other branches will read entries from the cache but will not write updated entries.
See [Optimizing cache effectiveness](#optimizing-cache-effectiveness) for a more detailed explanation.
In some circumstances it makes sense to change this default, and to configure a workflow Job to read existing cache entries but not to write changes back.
You can configure read-only caching for the `gradle-build-action` as follows:
```yaml
cache-read-only: true
```
You can also configure read-only caching only for certain branches:
```yaml
# Only write to the cache for builds on the 'main' and 'release' branches. (Default is 'main' only.)
# Builds on other branches will only read existing entries from the cache.
In certain circumstances it may be desirable to start with a clean Gradle User Home state, but to save that state at the end of a workflow Job:
```yaml
cache-write-only: true
```
### Overwriting an existing Gradle User Home
When the action detects that the Gradle User Home caches directory already exists (`~/.gradle/caches`), then by default it will not overwrite the existing content of this directory.
This can occur when a prior action initializes this directory, or when using a self-hosted runner that retains this directory between uses.
In this case the Job Summary will display a message like:
> Caching for gradle-build-action was disabled due to pre-existing Gradle User Home
If you want override the default and have the `gradle-build-action` caches overwrite existing content in the Gradle User Home, you can set the `cache-overwrite-existing` parameter to 'true':
```yaml
cache-overwrite-existing: true
```
### Incompatibility with other caching mechanisms
When using `gradle-build-action` we recommend that you avoid using other mechanisms to save and restore the Gradle User Home.
Specifically:
- Avoid using `actions/cache` configured to cache the Gradle User Home, [as described in this example](https://github.com/actions/cache/blob/main/examples.md#java---gradle).
- Avoid using `actions/setup-java` with the `cache: gradle` option, [as described here](https://github.com/actions/setup-java#caching-gradle-dependencies).
Using either of these mechanisms may interfere with the caching provided by this action. If you choose to use a different mechanism to save and restore the Gradle User Home, you should disable the caching provided by this action, as described above.
### Cache debugging and analysis
A report of all cache entries restored and saved is printed to the Job Summary when saving the cache entries.
This report can provide valuable insight into how much cache space is being used.
It is possible to enable additional debug logging for cache operations. You do via the `GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED` environment variable:
```yaml
env:
GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true
```
Note that this setting will also prevent certain cache operations from running in parallel, further assisting with debugging.
## How Gradle User Home caching works
### Properties of the GitHub Actions cache
The GitHub Actions cache has some properties that present problems for efficient caching of the Gradle User Home.
- Immutable entries: once a cache entry is written for a key, it cannot be overwritten or changed.
- Branch scope: cache entries written for a Git branch are not visible from actions running against different branches. Entries written for the default branch are visible to all. https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache
- Restore keys: if no exact match is found, a set of partial keys can be provided that will match by cache key prefix. https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#matching-a-cache-key
Each of these properties has influenced the design and implementation of the caching in `gradle-build-action`, as described below.
### Which content is cached
Using experiments and observations, we have attempted to identify which Gradle User Home content is worth saving and restoring between build invocations. We considered both the respective size of the content and the impact this content has on build times. As well as the obvious candidates like downloaded dependencies, we saw that compiled build scripts, transformed Jar files and other content can also have a significant impact.
In the end, we opted to save and restore as much content as is practical, including:
- `caches/<version>/generated-gradle-jars`: These files are generated on first use of a particular Gradle version, and are expensive to recreate
- `caches/<version>/kotlin-dsl` and `caches/<version>/scripts`: These are the compiled build scripts. The Kotlin ones in particular can benefit from caching.
- `caches/modules-2`: The downloaded dependencies
- `caches/transforms-3`: The results of artifact transforms
- `caches/jars-9`: Jar files that have been processed/instrumented by Gradle
- `caches/build-cache-1`: The local build cache
In certain cases a particular section of Gradle User Home will be too large to make caching effective. In these cases, particular subdirectories can be excluded from caching. See [Exclude content from Gradle User Home cache](#exclude-content-from-gradle-user-home-cache).
### Cache keys
The actual content of the Gradle User Home after a build is the result of many factors, including:
- The entire content of `buildSrc` or any included builds that provide plugins.
- The entire content of the repository, in the case of the local build cache.
- The actual build command that was invoked, including system properties and environment variables.
For this reason, it's very difficult to create a cache key that will deterministically map to a saved Gradle User Home state. So instead of trying to reliably hash all of these inputs to generate a cache key, the Gradle User Home cache key is based on the currently executing Job and the current commit hash for the repository.
The Gradle User Home cache key is composed of:
- The current operating system (`RUNNER_OS`)
- The workflow name and Job ID
- A hash of the Job matrix parameters
- The git SHA for the latest commit
Specifically, the cache key is: `${cache-protocol}-gradle|${runner-os}|${workflow-name}-${job-id}[${hash-of-job-matrix}]-${git-sha}`
As such, the cache key is likely to change on each subsequent run of GitHub actions.
This allows the most recent state to always be available in the GitHub actions cache.
### Finding a matching cache entry
In most cases, no exact match will exist for the cache key. Instead, the Gradle User Home will be restored for the closest matching cache entry, using a set of "restore keys". The entries will be matched with the following precedence:
- An exact match on OS, workflow, job, matrix and Git SHA
- The most recent entry saved for the same OS, workflow, job and matrix values
- The most recent entry saved for the same OS, workflow and job
- The most recent entry saved for the same OS
Due to branch scoping of cache entries, the above match will be first performed for entries from the same branch, and then for the default ('main') branch.
After the Job is complete, the current Gradle User Home state will be collected and written as a new cache entry with the complete cache key. Old entries will be expunged from the GitHub Actions cache on a least-recently-used basis.
Note that while effective, this mechanism is not inherently efficient. It requires the entire Gradle User Home directory to be stored separately for each branch, for every OS+Job+Matrix combination. In addition, a new cache entry to be written on every GitHub Actions run.
This inefficiency is effectively mitigated by [Deduplication of Gradle User Home cache entries](#deduplication-of-gradle-user-home-cache-entries), and can be further optimized for a workflow using the techniques described in [Optimizing cache effectiveness](#optimizing-cache-effectiveness).
### Deduplication of Gradle User Home cache entries
To reduce duplication between cache entries, certain artifacts in Gradle User Home are extracted and cached independently based on their identity. This allows each Gradle User Home cache entry to be relatively small, sharing common elements between them without duplication.
Artifacts that are cached independently include:
- Downloaded dependencies
- Downloaded wrapper distributions
- Generated Gradle API jars
- Downloaded Java Toolchains
For example, this means that all jobs executing a particular version of the Gradle wrapper will share a single common entry for this wrapper distribution and one for each of the generated Gradle API jars.
### Stopping the Gradle daemon
By default, the action will stop all running Gradle daemons in the post-action step, prior to saving the Gradle User Home state.
This allows for any Gradle User Home cleanup to occur, and avoid file-locking issues on Windows.
If caching is disabled or the cache is in read-only mode, the daemon will not be stopped and will continue running after the job is completed.
## Optimizing cache effectiveness
Cache storage space for GitHub actions is limited, and writing new cache entries can trigger the deletion of existing entries.
Eviction of shared cache entries can reduce cache effectiveness, slowing down your `gradle-build-action` steps.
There are a number of actions you can take if your cache use is less effective due to entry eviction.
At the end of a Job, the `gradle-build-action` will write a summary of the Gradle builds executed, together with a detailed report of the cache entries that were read and written during the Job. This report can provide valuable insights that may help to determine the right way to optimize the cache usage for your workflow.
### Select which jobs should write to the cache
Consider a workflow that first runs a Job "compile-and-unit-test" to compile the code and run some basic unit tests, which is followed by a matrix of parallel "integration-test" jobs that each run a set of integration tests for the repository. Each "integration test" Job requires all of the dependencies required by "compile-and-unit-test", and possibly one or 2 additional dependencies.
By default, a new cache entry will be written on completion of each integration test job. If no additional dependencies were downloaded then this cache entry will share the "dependencies" entry with the "compile-and-unit-test" job, but if a single dependency was downloaded then an entire new "dependencies" entry would be written. (The `gradle-build-action` does not _yet_ support a layered cache that could do this more efficiently). If each of these "integration-test" entries with their different "dependencies" entries is too large, then it could result in other important entries being evicted from the GitHub Actions cache.
There are some techniques that can be used to avoid/mitigate this issue:
- Configure the "integration-test" jobs with `cache-read-only: true`, meaning that the Job will use the entry written by the "compile-and-unit-test" job. This will avoid the overhead of cache entries for each of these jobs, at the expense of re-downloading any additional dependencies required by "integration-test".
- Add an additional step to the "compile-and-unit-test" job which downloads all dependencies required by the integration-test jobs but does not execute the tests. This will allow the "dependencies" entry for "compile-and-unit-test" to be shared among all cache entries for "integration-test". The resulting "integration-test" entries should be much smaller, reducing the potential for eviction.
- Combine the above 2 techniques, so that no cache entry is written by "integration-test" jobs, but all required dependencies are already present from the restored "compile-and-unit-test" entry.
### Select which branches should write to the cache
GitHub cache entries are not shared between builds on different branches.
This means that each PR branch will have it's own Gradle User Home cache, and will not benefit from cache entries written by other PR branches.
An exception to this is that cache entries written in parent and upstream branches are visible to child branches, and cache entries for the default (`master`/`main`) branch can be read by actions invoked for any other branch.
By default, the `gradle-build-action` will only _write_ to the cache for builds run on the default (`master`/`main`) branch.
Jobs run on other branches will only read from the cache. In most cases, this is the desired behaviour,
because Jobs run against other branches will benefit from the cache Gradle User Home from `main`,
without writing private cache entries that could lead to evicting shared entries.
If you have other long-lived development branches that would benefit from writing to the cache,
you can configure these by overriding the `cache-read-only` action parameter.
See [Using the cache read-only](#using-the-cache-read-only) for more details.
Similarly, you could use `cache-read-only` for certain jobs in the workflow, and instead have these jobs reuse the cache content from upstream jobs.
### Exclude content from Gradle User Home cache
As well as any wrapper distributions, the action will attempt to save and restore the `caches` and `notifications` directories from Gradle User Home.
Each build is different, and some builds produce more Gradle User Home content than others.
[Cache debugging ](#cache-debugging-and-analysis) can provide insight into which cache entries are the largest,
and the contents to be cached can be fine tuned by including and excluding certain paths within Gradle User Home.
```yaml
# Cache downloaded JDKs in addition to the default directories.
gradle-home-cache-includes: |
caches
notifications
jdks
# Exclude the local build-cache and keyrings from the directories cached.
gradle-home-cache-excludes: |
caches/build-cache-1
caches/keyrings
```
You can specify any number of fixed paths or patterns to include or exclude.
File pattern support is documented at https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#patterns-to-match-file-paths.
### Remove unused files from Gradle User Home before saving to cache
The Gradle User Home directory has a tendency to grow over time. When you switch to a new Gradle wrapper version or upgrade a dependency version
the old files are not automatically and immediately removed. While this can make sense in a local environment, in a GitHub Actions environment
it can lead to ever-larger Gradle User Home cache entries being saved and restored.
In order to avoid this situation, the `gradle-build-action` supports the `gradle-home-cache-cleanup` parameter.
When enabled, this feature will attempt to delete any files in the Gradle User Home that were not used by Gradle during the GitHub Actions workflow,
prior to saving the Gradle User Home to the GitHub Actions cache.
Gradle Home cache cleanup is considered experimental and is disabled by default. You can enable this feature for the action as follows:
```yaml
gradle-home-cache-cleanup: true
```
## Build reporting
The `gradle-build-action` collects information about any Gradle executions that occur in a workflow, and reports these via
a Job Summary, visible in the GitHub Actions UI. For each Gradle execution, details about the invocation are listed, together with
a link to any Build Scan® published.
Generation of a Job Summary is enabled by default. If this is not desired, it can be disable as follows:
```yaml
generate-job-summary: false
```
Note that the action collects information about Gradle invocations via an [Initialization Script](https://docs.gradle.org/current/userguide/init_scripts.html#sec:using_an_init_script)
located at `USER_HOME/.gradle/init.d/build-result-capture.init.gradle`.
If you are using init scripts for the [Gradle Enterprise Gradle Plugin](https://plugins.gradle.org/plugin/com.gradle.enterprise) like
[`scans-init.gradle` or `gradle-enterprise-init.gradle`](https://docs.gradle.com/enterprise/gradle-plugin/#scans_gradle_com),
you'll need to ensure these files are applied prior to `build-result-capture.init.gradle`.
Since Gradle applies init scripts in alphabetical order, one way to ensure this is via file naming.
### Build Scan® link as Step output
As well as reporting the [Build Scan](https://gradle.com/build-scans/) link in the Job Summary,
the `gradle-build-action` action makes this link available as a Step output named `build-scan-url`.
You can then use that link in subsequent actions of your workflow. For example:
By default, a GitHub Actions workflow using `gradle-build-action` will record the log output and any Build Scan links for your build,
but any output files generated by the build will not be saved.
To save selected files from your build execution, you can use the core [Upload-Artifact](https://github.com/actions/upload-artifact) action.
For example:
```yaml
jobs:
gradle:
runs-on: ubuntu-latest
steps:
- name: Checkout project sources
uses: actions/checkout@v4
- name: Setup Gradle
uses: gradle/gradle-build-action@v2
- name: Run build with Gradle wrapper
run: ./gradlew build --scan
- name: Upload build reports
uses: actions/upload-artifact@v3
if: always()
with:
name: build-reports
path: build/reports/
```
## Use the action to invoke Gradle
If the `gradle-build-action` is configured with an `arguments` input, then Gradle will execute a Gradle build with the arguments provided. NOTE: We recommend using the `gradle-build-action` as a "Setup Gradle" step as described above, with Gradle being invoked via a regular `run` command.
If no `arguments` are provided, the action will not execute Gradle, but will still cache Gradle state and configure build-scan capture for all subsequent Gradle executions.
```yaml
name: Run Gradle on PRs
on: pull_request
jobs:
gradle:
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v3
with:
distribution: temurin
java-version: 11
- name: Setup and execute Gradle 'test' task
uses: gradle/gradle-build-action@v2
with:
arguments: test
```
### Multiple Gradle executions in the same Job
It is possible to configure multiple Gradle executions to run sequentially in the same job.
The initial Action step will perform the Gradle setup.
```yaml
- uses: gradle/gradle-build-action@v2
with:
arguments: assemble
- uses: gradle/gradle-build-action@v2
with:
arguments: check
```
### Gradle command-line arguments
The `arguments` input can be used to pass arbitrary arguments to the `gradle` command line.
Arguments can be supplied in a single line, or as a multi-line input.
Here are some valid examples:
```yaml
arguments: build
arguments: check --scan
arguments: some arbitrary tasks
arguments: build -PgradleProperty=foo
arguments: |
build
--scan
-PgradleProperty=foo
-DsystemProperty=bar
```
If you need to pass environment variables, use the GitHub Actions workflow syntax:
```yaml
- uses: gradle/gradle-build-action@v2
env:
CI: true
with:
arguments: build
```
### Gradle build located in a subdirectory
By default, the action will execute Gradle in the root directory of your project.
Use the `build-root-directory` input to target a Gradle build in a subdirectory.
```yaml
- uses: gradle/gradle-build-action@v2
with:
arguments: build
build-root-directory: some/subdirectory
```
### Using a specific Gradle executable
The action will first look for a Gradle wrapper script in the root directory of your project.
If not found, `gradle` will be executed from the PATH.
Use the `gradle-executable` input to execute using a specific Gradle installation.
```yaml
- uses: gradle/gradle-build-action@v2
with:
arguments: build
gradle-executable: /path/to/installed/gradle
```
This mechanism can also be used to target a Gradle wrapper script that is located in a non-default location.
## Support for GitHub Enterprise Server (GHES)
You can use the `gradle-build-action` on GitHub Enterprise Server, and benefit from the improved integration with Gradle. Depending on the version of GHES you are running, certain features may be limited:
- Build Scan links are captured and displayed in the GitHub Actions UI
- Easily run your build with different versions of Gradle
- Save/restore of Gradle User Home (requires GHES v3.5+ : GitHub Actions cache was introduced in GHES 3.5)
- Support for GitHub Actions Job Summary (requires GHES 3.6+ : GitHub Actions Job Summary support was introduced in GHES 3.6). In earlier versions of GHES the build-results summary and caching report will be written to the workflow log, as part of the post-action step.
# GitHub Dependency Graph support
The `gradle-build-action` has support for submitting a [GitHub Dependency Graph](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph) snapshot via the [GitHub Dependency Submission API](https://docs.github.com/en/rest/dependency-graph/dependency-submission?apiVersion=2022-11-28).
The dependency graph snapshot is generated via integration with the [GitHub Dependency Graph Gradle Plugin](https://plugins.gradle.org/plugin/org.gradle.github-dependency-graph-gradle-plugin), and saved as a workflow artifact. The generated snapshot files can be submitted either in the same job, or in a subsequent job (in the same or a dependent workflow).
The generated dependency graph snapshot reports all of the dependencies that were resolved during a build execution, and is used by GitHub to generate [Dependabot Alerts](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) for vulnerable dependencies, as well as to populate the [Dependency Graph insights view](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/exploring-the-dependencies-of-a-repository#viewing-the-dependency-graph).
## Enable Dependency Graph generation for a workflow
You enable GitHub Dependency Graph support by setting the `dependency-graph` action parameter. Valid values are:
| Option | Behaviour |
| --- | --- |
| `disabled` | Do not generate a dependency graph for any build invocations.<p>This is the default. |
| `generate` | Generate a dependency graph snapshot for each build invocation, saving as a workflow artifact. |
| `generate-and-submit` | As per `generate`, but any generated dependency graph snapshots will be submitted at the end of the job. |
| `download-and-submit` | Download any previously saved dependency graph snapshots, submitting them via the Dependency Submission API. This can be useful to collect all snapshots in a matrix of builds and submit them in one step. |
Example of a CI workflow that generates and submits a dependency graph:
```yaml
name: CI build
on:
on:
push:
push:
permissions:
contents: write
jobs:
jobs:
build:
build:
runs-on: ubuntu-latest
runs-on: ubuntu-latest
steps:
steps:
- uses: actions/checkout@v4
- name: Checkout sources
- name: Setup Gradle to generate and submit dependency graphs
uses: actions/checkout@v4
uses: gradle/gradle-build-action@v2
- name: Setup Java
uses: actions/setup-java@v4
with:
with:
dependency-graph: generate-and-submit
distribution: 'temurin'
- name: Run the usual CI build (dependency-graph will be generated and submitted post-job)
java-version: 17
run: ./gradlew build
```
The `contents: write` permission is required in order to submit (but not generate) the dependency graph file.
Depending on [repository settings](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token), this permission may be available by default or may need to be explicitly enabled in the workflow file (as above).
> [!IMPORTANT]
> The above configuration will work for workflows that run as a result of commits to a repository branch,
> but not when a workflow is triggered by a PR from a repository fork.
> This is because the `contents: write` permission is not available when executing a workflow
> for a PR submitted from a forked repository.
> For a configuration that supports this setup, see [Dependency Graphs for pull request workflows](#dependency-graphs-for-pull-request-workflows).
### Using a custom plugin repository
By default, the action downloads the `github-dependency-graph-gradle-plugin` from the Gradle Plugin Portal (https://plugins.gradle.org). If your GitHub Actions environment does not have access to this URL, you can specify a custom plugin repository to use.
Do so by setting the `GRADLE_PLUGIN_REPOSITORY_URL` environment variable with your Gradle invocation.
```yaml
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Gradle to generate and submit dependency graphs
uses: gradle/gradle-build-action@v2
with:
dependency-graph: generate-and-submit
- name: Run a build, resolving the 'dependency-graph' plugin from the plugin portal proxy
The GitHub [dependency-review-action](https://github.com/actions/dependency-review-action) helps you
understand dependency changes (and the security impact of these changes) for a pull request.
For the `dependency-review-action` to succeed, it must run _after_ the dependency graph has been submitted for a PR.
When using `generate-and-submit`, dependency graph files are submitted at the end of the job, after all steps have been
executed. For this reason, the `dependency-review-action` must be executed in a dependent job,
and not as a subsequent step in the job that generates the dependency graph.
Example of a pull request workflow that executes a build for a pull request and runs the `dependency-review-action`:
```yaml
name: PR check
on:
pull_request:
permissions:
contents: write
# Note that this permission will not be available if the PR is from a forked repository
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Gradle to generate and submit dependency graphs
uses: gradle/gradle-build-action@v2
with:
dependency-graph: generate-and-submit
- name: Run a build and generate the dependency graph which will be submitted post-job
run: ./gradlew build
dependency-review:
needs: build
runs-on: ubuntu-latest
- name: Perform dependency review
uses: actions/dependency-review-action@v3
```
See [Dependency Graphs for pull request workflows](#dependency-graphs-for-pull-request-workflows) for a more complex
(and less functional) example that will work for pull requests submitted from forked repositories.
## Limiting the scope of the dependency graph
At times it is helpful to limit the dependencies reported to GitHub, in order to security alerts for dependencies that don't form a critical part of your product.
For example, a vulnerability in the tool you use to generate documentation is unlikely to be as important as a vulnerability in one of your runtime dependencies.
There are a number of techniques you can employ to limit the scope of the generated dependency graph:
- [Don't generate a dependency graph for all Gradle executions](#choosing-which-gradle-invocations-will-generate-a-dependency-graph)
- [For a Gradle execution, filter which Gradle projects and configurations will contribute dependencies](#filtering-which-gradle-configurations-contribute-to-the-dependency-graph)
- [Use a separate workflow that only resolves the required dependencies](#use-a-dedicated-workflow-for-dependency-graph-generation)
> [!NOTE]
> Ideally, all dependencies involved in building and testing a project will be extracted and reported in a dependency graph.
> These dependencies would be assigned to different scopes (eg development, runtime, testing) and the GitHub UI would make it easy to opt-in to security alerts for different dependency scopes.
> However, this functionality does not yet exist.
### Choosing which Gradle invocations will generate a dependency graph
Once you enable the dependency graph support for a workflow job (via the `dependency-graph` parameter), dependencies will be collected and reported for all subsequent Gradle invocations.
If you have a Gradle build step that you want to exclude from dependency graph generation, you can set the `GITHUB_DEPENDENCY_GRAPH_ENABLED` environment variable to `false`.
```yaml
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Gradle to generate and submit dependency graphs
uses: gradle/gradle-build-action@v2
with:
dependency-graph: generate-and-submit
- name: Build the app, generating a graph of dependencies required
run: ./gradlew :my-app:assemble
- name: Run all checks, disabling dependency graph generation
run: ./gradlew check
env:
GITHUB_DEPENDENCY_GRAPH_ENABLED: false
```
### Filtering which Gradle Configurations contribute to the dependency graph
If you do not want the dependency graph to include every dependency configuration in every project in your build, you can limit the
dependency extraction to a subset of these.
To restrict which Gradle subprojects contribute to the report, specify which projects to include via a regular expression.
You can provide this value via the `DEPENDENCY_GRAPH_INCLUDE_PROJECTS` environment variable or system property.
To restrict which Gradle configurations contribute to the report, you can filter configurations by name using a regular expression.
You can provide this value via the `DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS` environment variable or system property.
For example, if you want to exclude dependencies in the `buildSrc` project, and only report on dependencies from the `runtimeClasspath` configuration,
you would use the following configuration:
```yaml
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Gradle to generate and submit dependency graphs
uses: gradle/gradle-build-action@v2
with:
dependency-graph: generate-and-submit
- name: Run a build, generating the dependency graph from any resolved 'runtimeClasspath' configurations
### Use a dedicated workflow for dependency graph generation
Instead of generating a dependency graph from your existing CI workflow, it's possible to create a separate dedicated workflow (or Job) that is intended for generating a dependency graph.
Such a workflow will still need to execute Gradle, but can do so in a way that is targeted at resolving the specific dependencies required.
For example, the following workflow will report those dependencies that are resolved in order to build the `distributionZip` for the `my-app` project. Test dependencies and other dependencies not required by the `distributionZip` will not be included.
```yaml
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Gradle to generate and submit dependency graphs
uses: gradle/gradle-build-action@v2
with:
dependency-graph: generate-and-submit
- name: Build the distribution Zip for `my-app`
run: ./gradlew :my-app:distributionZip
```
Note that the above example will also include any `buildSrc` dependencies, dependencies resolved when configuring your Gradle build or dependencies resolved while applying plugin. All of these dependencies are resolved in the process of running the `distributionZip` task, and thus will form part of the generated dependency graph.
If this isn't desirable, you will still need to use the filtering mechanism described above.
## Dependency Graphs for pull request workflows
This `contents: write` permission is not available for any workflow that is triggered by a pull request submitted from a forked repository, since it would permit a malicious pull request to make repository changes.
Because of this restriction, it is not possible to `generate-and-submit` a dependency graph generated for a pull-request that comes from a repository fork. In order to do so, 2 workflows will be required:
1. The first workflow runs directly against the pull request sources and will generate the dependency graph snapshot.
2. The second workflow is triggered on `workflow_run` of the first workflow, and will submit the previously saved dependency snapshots.
Note: when `download-and-submit` is used in a workflow triggered via [workflow_run](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run), the action will download snapshots saved in the triggering workflow.
***Main workflow file***
```yaml
name: run-build-and-generate-dependency-snapshot
on:
pull_request:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Gradle to generate and submit dependency graphs
uses: gradle/gradle-build-action@v2
with:
dependency-graph: generate # Only generate in this job
- name: Run a build, generating the dependency graph snapshot which will be submitted
- name: Retrieve dependency graph artifact and submit
uses: gradle/gradle-build-action@v2
with:
dependency-graph: download-and-submit
```
### Integrating `dependency-review-action` for pull request workflows
The GitHub [dependency-review-action](https://github.com/actions/dependency-review-action) helps you
understand dependency changes (and the security impact of these changes) for a pull request.
To integrate the `dependency-review-action` into the pull request workflows above, a separate workflow should be added.
This workflow will be triggered directly on `pull_request`, but will need to wait until the dependency graph results are
submitted before the dependency review can complete. How long to wait is controlled by the `retry-on-snapshot-warnings` input parameters.
Here's an example of a separate "Dependency Review" workflow that will wait for 10 minutes for the PR check workflow to complete.
```yaml
name: dependency-review
on:
pull_request:
permissions:
contents: read
pull-requests: write
jobs:
dependency-review:
runs-on: ubuntu-latest
steps:
- name: 'Dependency Review'
uses: actions/dependency-review-action@v3
with:
retry-on-snapshot-warnings: true
retry-on-snapshot-warnings-timeout: 600
```
The `retry-on-snapshot-warnings-timeout` (in seconds) needs to be long enough to allow the entire `run-build-and-generate-dependency-snapshot` and `submit-dependency-snapshot` workflows (above) to complete.
## Gradle version compatibility
The GitHub Dependency Graph plugin should be compatible with all versions of Gradle >= 5.0, and has been tested against
Gradle versions "5.6.4", "6.9.4", "7.0.2", "7.6.2", "8.0.2" and the current Gradle release.
The plugin is compatible with running Gradle with the configuration-cache enabled. However, this support is
limited to Gradle "8.1.0" and later:
- With Gradle "8.0", the build should run successfully, but an empty dependency graph will be generated.
- With Gradle <= "7.6.4", the plugin will cause the build to fail with configuration-cache enabled.
To use this plugin with versions of Gradle older than "8.1.0", you'll need to invoke Gradle with the
configuration-cache disabled.
## Reducing storage costs for saved dependency graph artifacts
When `generate` or `generate-and-submit` is used with the action, the dependency graph that is generated is stored as a workflow artifact.
By default, these artifacts are retained for a period of 30 days (or as configured for the repository).
To reduce storage costs for these artifacts, you can set the `artifact-retention-days` value to a lower number.
```yaml
steps:
- name: Generate dependency graph, but only retain artifact for one day
uses: gradle/gradle-build-action@v2
with:
dependency-graph: generate
artifact-retention-days: 1
```
# Gradle Enterprise plugin injection
The `gradle-build-action` provides support for injecting and configuring the Gradle Enterprise Gradle plugin into any Gradle build, without any modification to the project sources.
This is achieved via an init-script installed into Gradle User Home, which is enabled and parameterized via environment variables.
The same auto-injection behavior is available for the Common Custom User Data Gradle plugin, which enriches any build scans published with additional useful information.
## Enabling Gradle Enterprise injection
In order to enable Gradle Enterprise for your build, you must provide the required configuration via environment variables.
Here's a minimal example:
```yaml
name: Run build with Gradle Enterprise injection
env:
GRADLE_ENTERPRISE_INJECTION_ENABLED: true
GRADLE_ENTERPRISE_URL: https://ge.gradle.org
GRADLE_ENTERPRISE_PLUGIN_VERSION: 3.15.1
GRADLE_ENTERPRISE_ACCESS_KEY: ${{ secrets.GE_ACCESS_KEY }} # Required to publish scans to ge.gradle.org
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Gradle
- name: Setup Gradle
uses: gradle/gradle-build-action@v2
uses: gradle/actions/setup-gradle@v4
- name: Run a Gradle build with Gradle Enterprise injection enabled
- name: Build with Gradle
run: ./gradlew build
run: ./gradlew build
```
```
This configuration will automatically apply `v3.15.1` of the [Gradle Enterprise Gradle plugin](https://docs.gradle.com/enterprise/gradle-plugin/), and publish build scans to https://ge.gradle.org.
See the [full action documentation](docs/setup-gradle.md) for more advanced usage scenarios.
Note that the `ge.gradle.org` server requires authentication in order to publish scans. The provided `GRADLE_ENTERPRISE_ACCESS_KEY` isn't required by the Gradle Enterprise injection script,
## The `dependency-submission` action
but will be used by the GE plugin in order to authenticate with the server.
## Configuring Gradle Enterprise injection
Generates and submits a dependency graph for a Gradle project, allowing GitHub to alert about reported vulnerabilities in your project dependencies.
The `init-script` supports a number of additional configuration parameters that you may fine useful. All configuration options (required and optional) are detailed below:
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.
| Variable | Required | Description |
Simply add this as a new workflow file to your repository (eg `.github/workflows/dependency-submission.yml`).
| GRADLE_ENTERPRISE_URL | :white_check_mark: | the URL of the Gradle Enterprise server |
| GRADLE_ENTERPRISE_ALLOW_UNTRUSTED_SERVER | | allow communication with an untrusted server; set to _true_ if your Gradle Enterprise instance is using a self-signed certificate |
| GRADLE_ENTERPRISE_ENFORCE_URL | | enforce the configured Gradle Enterprise URL over a URL configured in the project's build; set to _true_ to enforce publication of build scans to the configured Gradle Enterprise URL |
| GRADLE_ENTERPRISE_PLUGIN_VERSION | :white_check_mark: | the version of the [Gradle Enterprise Gradle plugin](https://docs.gradle.com/enterprise/gradle-plugin/) to apply |
| GRADLE_ENTERPRISE_CCUD_PLUGIN_VERSION | | the version of the [Common Custom User Data Gradle plugin](https://github.com/gradle/common-custom-user-data-gradle-plugin) to apply, if any |
| GRADLE_ENTERPRISE_PLUGIN_REPOSITORY_URL | | the URL of the repository to use when resolving the GE and CCUD plugins; the Gradle Plugin Portal is used by default |
## Publishing to scans.gradle.com
```yaml
name: Dependency Submission
Gradle Enterprise injection is designed to enable publishing of build scans to a Gradle Enterprise instance,
on:
and is not suitable for publishing to the public Build Scans instance (https://scans.gradle.com).
push:
branches: [ 'main' ]
In order to publish Build Scans to scans.gradle.com, you need to:
permissions:
- Apply the Gradle Enterprise plugin to your build configuration ([see docs](https://docs.gradle.com/enterprise/get-started/#applying_the_plugin))
contents: write
- Programmatically accept the Terms of Service for scans.gradle.com ([see docs](https://docs.gradle.com/enterprise/gradle-plugin/#connecting_to_scans_gradle_com))
- Execute the build with `--scan` or configure your build with `publishAlways()` ([see docs](https://docs.gradle.com/enterprise/get-started/#always_publishing_a_build_scan))
jobs:
dependency-submission:
runs-on: ubuntu-latest
steps:
- name: Checkout sources
uses: actions/checkout@v4
- name: Setup Java
uses: actions/setup-java@v4
with:
distribution: 'temurin'
java-version: 17
- name: Generate and submit dependency graph
uses: gradle/actions/dependency-submission@v4
```
See the [full action documentation](docs/dependency-submission.md) for more advanced usage scenarios.
## The `wrapper-validation` action
The `wrapper-validation` action validates the checksums of _all_ [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html) 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](docs/setup-gradle.md#gradle-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
```yaml
name: "Validate Gradle Wrapper"
on:
push:
pull_request:
jobs:
validation:
name: "Validation"
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: gradle/actions/wrapper-validation@v4
```
See the [full action documentation](docs/wrapper-validation.md) for more advanced usage scenarios.
- Check that https://github.com/gradle/actions/actions is green for all workflows for the main branch.
- This should include any workflows triggered by `[bot] Update dist directory`
- Decide on the version number to use for the release. The action releases should follow semantic versioning.
- By default, a patch release is assumed (eg. `4.0.0` → `4.0.1`)
- If new features have been added, bump the minor version (eg `4.1.1` → `4.2.0`)
- If a new major release is required, bump the major version (eg `4.1.1` → `5.0.0`)
- Note: The gradle actions follow the GitHub Actions convention of including a .0 patch number for the first release of a minor version, unlike the Gradle convention which omits the trailing .0.
## Release gradle/actions
- Create a tag for the release. The tag should have the format `v4.1.0`
- From CLI: `git tag -s -m "v4.1.0" v4.1.0 && git push --tags`
- Note that we sign the tag and set the commit message for the tag to the newly released version.
- Go to https://github.com/gradle/actions/releases and "Draft new release"
- Use the newly created tag and copy the tag name exactly as the release title.
- Craft release notes content based on issues closed, PRs merged and commits
- Include a Full changelog link in the format https://github.com/gradle/actions/compare/v2.12.0...v3.0.0
- Publish the release.
- Force push the `v4` tag (or current major version) to point to the new release. It is conventional for users to bind to a major release version using this tag.
- From CLI: `git tag -f -s -a -m "v4.0.0" v4 v4.0.0 && git push -f --tags`
- Note that we sign the tag and set the commit message for the tag to the newly released version.
## Post release steps
Submit PRs to update the GitHub starter workflow. Starter workflows contain content that should reference the Git hash of the current gradle/actions release:
https://github.com/actions/starter-workflows has [gradle](https://github.com/actions/starter-workflows/blob/main/ci/gradle.yml) and [gradle-publish](https://github.com/actions/starter-workflows/blob/main/ci/gradle-publish.yml): see [the v4.0.0 update PR](https://github.com/actions/starter-workflows/pull/2468) for an example.
Submit PRs to update the GitHub documentation. The documentation contains content that should reference the Git hash of the current gradle/actions release:
https://github.com/github/docs has [building-and-testing-java-with-gradle](https://github.com/github/docs/blob/main/content/actions/automating-builds-and-tests/building-and-testing-java-with-gradle.md) and [publishing-java-packages-with-gradle](https://github.com/github/docs/blob/main/content/actions/publishing-packages/publishing-java-packages-with-gradle.md) : see [the v4.0.0 update PR](https://github.com/github/docs/pull/34239) for an example.
When 'true', entries will not be restored from the cache but will be saved at the end of the Job.
Setting this to 'true' implies cache-read-only will be 'false'.
required:false
default:false
cache-overwrite-existing:
description:When 'true', a pre-existing Gradle User Home will not prevent the cache from being restored.
required:false
default:false
gradle-home-cache-includes:
description:Paths within Gradle User Home to cache.
required:false
default:|
caches
notifications
gradle-home-cache-excludes:
description:Paths within Gradle User Home to exclude from cache.
required:false
# e.g. Use the following setting to prevent the local build cache from being saved/restored
# gradle-home-cache-excludes: |
# caches/build-cache-1
gradle-home-cache-cleanup:
description:When 'true', the action will attempt to remove any stale/unused entries from the Gradle User Home prior to saving to the GitHub Actions cache.
required:false
default:false
arguments:
description:Gradle command line arguments (supports multi-line input)
required:false
generate-job-summary:
description:When 'false', no Job Summary will be generated for the Job.
required:false
default:true
dependency-graph:
description:Specifies if a GitHub dependency snapshot should be generated for each Gradle build, and if so, how. Valid values are 'disabled' (default), 'generate', 'generate-and-submit' and 'download-and-submit'.
required:false
default:'disabled'
artifact-retention-days:
description:Specifies the number of days to retain any artifacts generated by the action. If not set, the default retention settings for the repository will apply.
required:false
# EXPERIMENTAL & INTERNAL ACTION INPUTS
# The following action properties allow fine-grained tweaking of the action caching behaviour.
# These properties are experimental and not (yet) designed for production use, and may change without notice in a subsequent release of `gradle-build-action`.
# Use at your own risk!
gradle-home-cache-strict-match:
description:When 'true', the action will not attempt to restore the Gradle User Home entries from other Jobs.
required:false
default:false
workflow-job-context:
description:Used to uniquely identify the current job invocation. Defaults to the matrix values for this job; this should not be overridden by users (INTERNAL).
required:false
default:${{ toJSON(matrix) }}
github-token:
description:The GitHub token used to authenticate when submitting via the Dependency Submission API.
default:${{ github.token }}
required:false
outputs:
build-scan-url:
description:Link to the Build Scan® generated by a Gradle build. Note that this output applies to a Step executing Gradle, not to the `gradle-build-action` Step itself.
dependency-graph-file:
description:Path to the GitHub Dependency Graph snapshot file generated by a Gradle build. Note that this output applies to a Step executing Gradle, not to the `gradle-build-action` Step itself.
gradle-version:
description:Version of Gradle that was setup by the action
runs:
runs:
using:'node16'
using:"composite"
main:'dist/main/index.js'
steps:
post:'dist/post/index.js'
- run:|
echo "::error::The path 'gradle/actions' is not a valid action. Please use 'gradle/actions/setup-gradle' or 'gradle/actions/dependency-submission'."
When 'true', entries will not be restored from the cache but will be saved at the end of the Job.
Setting this to 'true' implies cache-read-only will be 'false'.
required:false
default:false
cache-overwrite-existing:
description:When 'true', a pre-existing Gradle User Home will not prevent the cache from being restored.
required:false
default:false
cache-encryption-key:
description:|
A base64 encoded AES key used to encrypt the configuration-cache data. The key is exported as 'GRADLE_ENCRYPTION_KEY' for later steps.
A suitable key can be generated with `openssl rand -base64 16`.
Configuration-cache data will not be saved/restored without an encryption key being provided.
required:false
cache-cleanup:
description:|
Specifies if the action should attempt to remove any stale/unused entries from the Gradle User Home prior to saving to the GitHub Actions cache.
By default ('on-success'), cleanup is performed when all Gradle builds succeed for the Job.
This behaviour can be disabled ('never'), or configured to always run irrespective of the build outcome ('always').
Valid values are 'never', 'on-success' and 'always'.
required:false
default:'on-success'
gradle-home-cache-cleanup:
description:When 'true', the action will attempt to remove any stale/unused entries from the Gradle User Home prior to saving to the GitHub Actions cache.
required:false
deprecation-message:This input has been superceded by the 'cache-cleanup' input parameter.
gradle-home-cache-includes:
description:Paths within Gradle User Home to cache.
required:false
default:|
caches
notifications
gradle-home-cache-excludes:
description:Paths within Gradle User Home to exclude from cache.
required:false
# Job summary configuration
add-job-summary:
description:Specifies when a Job Summary should be inluded in the action results. Valid values are 'never', 'always' (default), and 'on-failure'.
required:false
default:'always'
add-job-summary-as-pr-comment:
description:Specifies when each Job Summary should be added as a PR comment. Valid values are 'never' (default), 'always', and 'on-failure'. No action will be taken if the workflow was not triggered from a pull request.
required:false
default:'never'
# Dependency Graph configuration
dependency-graph:
description:|
Specifies how the dependency-graph should be handled by this action.
By default a dependency-graph will be generated, submitted to the dependency-submission API, and saved as a workflow artifact.
Valid values are:
'generate-and-submit':Generates a dependency graph for the project and submits it in the same Job.
'generate-submit-and-upload (default)':As per 'generate-and-submit', but also saves the dependency graph as a workflow artifact.
'generate-and-upload':Generates a dependency graph for the project and saves it as a workflow artifact. Does not submit it to the repository.
'download-and-submit':Retrieves a previously saved dependency-graph and submits it to the repository.
Use `generate-and-submit` if you prefer not to save the dependency-graph as a workflow artifact.
The `generate-and-upload` and `download-and-submit` options are designed to be used in an untrusted workflow scenario,
where the workflow generating the dependency-graph cannot (or should not) be given the `contents:write` permissions
required to submit via the Dependency Submission API.
required:false
default:'generate-submit-and-upload'
dependency-graph-report-dir:
description:|
Specifies where the dependency graph report will be generated.
Paths can relative or absolute. Relative paths are resolved relative to the workspace directory.
required:false
default:'dependency-graph-reports'
dependency-graph-continue-on-failure:
description:When 'false' a failure to generate or submit a dependency graph will fail the Step or Job. When 'true' a warning will be emitted but no failure will result.
required:false
default:false
dependency-graph-exclude-projects:
description:|
Gradle projects that should be excluded from dependency graph (regular expression).
When set, any matching project will be excluded.
required:false
dependency-graph-include-projects:
description:|
Gradle projects that should be included in dependency graph (regular expression).
When set, only matching projects will be included.
required:false
dependency-graph-exclude-configurations:
description:|
Gradle configurations that should be included in dependency graph (regular expression).
When set, anymatching configurations will be excluded.
required:false
dependency-graph-include-configurations:
description:|
Gradle configurations that should be included in dependency graph (regular expression).
When set, only matching configurations will be included.
required:false
artifact-retention-days:
description:Specifies the number of days to retain any artifacts generated by the action. If not set, the default retention settings for the repository will apply.
required:false
# Build Scan configuration
build-scan-publish:
description:|
Set to 'true' to automatically publish build results as a Build Scan on scans.gradle.com.
For publication to succeed without user input, you must also provide values for `build-scan-terms-of-use-url` and 'build-scan-terms-of-use-agree'.
required:false
default:false
build-scan-terms-of-use-url:
description:The URL to the Build Scan® terms of use. This input must be set to 'https://gradle.com/terms-of-service' or 'https://gradle.com/help/legal-terms-of-use'.
required:false
build-scan-terms-of-use-agree:
description:Indicate that you agree to the Build Scan® terms of use. This input value must be "yes".
required:false
develocity-access-key:
description:Develocity access key. Should be set to a secret containing the Develocity Access key.
required:false
develocity-token-expiry:
description:The Develocity short-lived access tokens expiry in hours. Default is 2 hours.
required:false
# Wrapper validation configuration
validate-wrappers:
description:|
When 'true' the action will automatically validate all wrapper jars found in the repository.
If the wrapper checksums are not valid, the action will fail.
required:false
default:false
allow-snapshot-wrappers:
description:|
When 'true', wrapper validation will include the checksums of snapshot wrapper jars.
Use this if you are running with nightly or snapshot versions of the Gradle wrapper.
required:false
default:false
# DEPRECATED ACTION INPUTS
# EXPERIMENTAL ACTION INPUTS
# The following action properties allow fine-grained tweaking of the action caching behaviour.
# These properties are experimental and not (yet) designed for production use, and may change without notice in a subsequent release of `setup-gradle`.
# Use at your own risk!
gradle-home-cache-strict-match:
description:When 'true', the action will not attempt to restore the Gradle User Home entries from other Jobs.
required:false
default:false
# INTERNAL ACTION INPUTS
# These inputs should not be configured directly, and are only used to pass environmental information to the action
workflow-job-context:
description:Used to uniquely identify the current job invocation. Defaults to the matrix values for this job; this should not be overridden by users (INTERNAL).
required:false
default:${{ toJSON(matrix) }}
github-token:
description:The GitHub token used to authenticate when submitting via the Dependency Submission API.
default:${{ github.token }}
required:false
outputs:
build-scan-url:
description:Link to the Build Scan® generated by a Gradle build. Note that this output applies to a Step executing Gradle, not to the `setup-gradle` Step itself.
dependency-graph-file:
description:Path to the GitHub Dependency Graph snapshot file generated by a Gradle build. Note that this output applies to a Step executing Gradle, not to the `setup-gradle` Step itself.
gradle-version:
description:Version of Gradle that was setup by the action
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
