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
cd62d9c9ef.
- 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="https://github.com/gradle/gradle-build-action/commit/a8f75513eafdebd8141bd1cd4e30fcd194af8dfa"><code>a8f7551</code></a>
Build outputs</li>
<li><a
href="https://github.com/gradle/gradle-build-action/commit/9283312acb2f03f47ca40702fbba3a42a81047a2"><code>9283312</code></a>
Add new option to clear dependency-graph</li>
<li><a
href="https://github.com/gradle/gradle-build-action/commit/7c8a278ea037b3ba08ccf2147b8ba80be977578e"><code>7c8a278</code></a>
Remove old clear-dependency-graph action</li>
<li><a
href="https://github.com/gradle/gradle-build-action/commit/d8ca9b7d2e81bf7bfcb000dc25ef59c87acf81e1"><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.
The `PluginManager` type wasn't introduced until Gradle 2.x.
Remove this type from the method signature in an attempt to allow this
file to be parsed with Gradle 1.12.
The repository URL used to resolve the `github-dependency-graph-gradle-plugin` is now
configurable, allowing a user to specify an internal proxy if the public portal is not available.
Specify a custom plugin repository using the `GRADLE_PLUGIN_REPOSITORY_URL` env var,
or the `gradle.plugin-repository.url` System property.
Fixes#933
* dd/dependency-updates:
Bumps the npm-dependencies group with 5 updates:
Bump the github-actions group with 2 updates
Bump from Gradle 8.4 to Gradle 8.5
- Added a new `artifact-retention-days` input parameter to control retention of uploaded artifacts
- Artifacts retention will use repository settings if not overridden.
A common issue when submitting a dependency graph is that the required
'contents: write' permission is not set.
We now catch any dependency submission failure and inform the user to check
that the required permissions are available.
When using 'download-and-submit' for dependency graphs, we now run the
submission immediately instead of waiting until the post-action.
This allows a single job to both submit the graph and run the dependency
review action.
- Allow environment variables to be overridden by system properties in dependency-graph initscript
- Set `GITHUB_DEPENDENCY_GRAPH_ENABLED=false` when executing Gradle for cache cleanup
In a pull request, GITHUB_SHA is set to the "last merge commit on the GITHUB_REF branch".
This isn't the correct value to use when generating a dependency graph.
This changes to use the value of `pull_request.head.sha`, which is the correct
value for a dependency graph.
Fixes#882
Adds a new init-script which can enable and configure the Gradle Enterprise plugin(s)
for a build, without needing to modify the settings script for the project.
The functionality is enabled and configured via environment variables or system properties.
Not yet wired into `gradle-build-action`.
- Describe the limitations/properties of the GitHub Actions cache
- Document the algorithm for generating a cache key, and the way that cache entries are matched
- Describe in more detail how entries are de-duplicated
- Explain how cache entries can be optimized in Job pipelines
Fixes#831Fixes#608
Users will currently need to spend some time working out the required regex when using `DEPENDENCY_GRAPH_INCLUDE_PROJECTS`. Providing an example will get users up to speed quicker.
Signed-off-by: Andy Coates <8012398+big-andy-coates@users.noreply.github.com>
Fixes: #840
With Gradle 8.0.2 (not tried other versions) the configuration name is runtimeClasspath not RuntimeClasspath. Using the latter results in an empty set of dependencies being reported (as it matches no configurations).
Signed-off-by: Andy Coates <8012398+big-andy-coates@users.noreply.github.com>
If an existing dependency graph file is present for the configured job correlator,
we now generate a unique correlator value for the invocation. This allows the action
to submit dependency snapshots for a series of Gradle invocations within the same Job.
This commit updates to `github-dependency-graph-gradle-plugin@v0.0.6`, which reduces
redundancy in the mapping of resolved Gradle dependencies to the GitHub Dependency Graph.
Adds a 'dependency-graph' parameter that has 4 options:
1. 'disabled': no dependency graph files generated (the default)
2. 'generate': dependency graph files will be generated and saved as artifacts.
3. 'generate-and-submit': dependency graph files will be generated, saved as artifacts,
and submitted to the Dependency Submission API on job completion.
4. 'download-and-submit': any previously uploaded dependency graph artifacts will be downloaded
and submitted to the Dependency Submission API.
Instead of requiring an action step to generate the graph, configure Gradle User Home
so that subsequent Gradle invocations can generate a graph. Any generated graph files
are uploaded as artifacts on job completion.
- Construct job.correlator from workflow/job/matrix
- Export job.correlator as an environment var
- Upload artifacts at job completion in post-action step
- Specify the location of dependency graph report
- Only apply dependency graph init script when explicitly enabled
Moved reading of all input parameters into a common source: `input-params.ts`.
This centralized all input parameter reads, and allowed an improved implementation
of reading boolean parameters. In particular, the implementation now provides a default
value for a boolean input parameter that isn't declared for an action.
Introducing new actions for the GitHub dependency graph will involve reuse of much of
the action infrastructure. This commit reorganises things a little to facilitate reuse.
The `PluginManager.hasPlugin` method was not detecting the GE plugin when it
was applied during settingsEvaluated.
Switching to `PluginManager.withPlugin` fixes this.
Fixes#626
With Gradle 8.1, the configuration-cache has changed and is now stable.
As a temporary measure, this commit disables save/restore of the configuration-cache
data to avoid issues until we can deal with this change properly.
When configuration-cache is enabled, the invocationId may not be unique, which can result in
mulitple builds writing to the same file. Rather than failing the post-action, we simply
ignore any subsequent build results with the same ID.
Fixes#441
Logging of the AZURE_LOG_LEVEL env var value is considered a security issue,
since any environment variable value could contain sensitive information.
In this case, logging the value is not really necessary.
The included sourcemap-register.js file is triggering a high priority
CodeQL warning, which can prevent users from adopting the action.
Removing this sourcemap support for now, until this can be fixed upstream.
- Bump eslint from 8.23.0 to 8.23.1
- Bump typescript from 4.8.2 to 4.8.3
- Bump eslint-plugin-jest from 27.0.1 to 27.0.4
- Bump @typescript-eslint/parser from 5.36.2 to 5.37.0
- Includes basic implementation as `CacheCleaner`
- Integration test that checks unused files are removed:
- Downloaded dependencies
- Local build cache entries
- Wrapper distributions
Now that `@actions/cache` provides a env var override, we can remove our
custom configuration for setting the timeout on cache restore operations.
If the env var is NOT set, we continue to override the 60min default with 10mins.
It appears that when restoring the Gradle User Home directory, certain empty
directories are being identified by Node as broken symlinks. This results in
`Error: ENOENT: No such file or directory` when attempting to resolve a Glob pattern.
By using the default behaviour of Globber (followSymbolicLinks && ignoreBrokenLinks),
these bad files no longer cause errors when saving the Gradle User Home to cache.
Fixes#408
The fix for #383 introduced a bug that caused the post-action to fail when
attemping to resolve `cache-read-only` for scheduled jobs.
This has been fixed with an explicit (rather than implicit) check for 'event.repository != null'.
Fixes#409
This commit reverts the change in v3.0.0 of @actions/cache, that
causes cache errors to be logged and swallowed. By allowing these
errors to propogate, the action can take appropriate action and
provide useful error messages.
Fixes#407
For scheduled workflows, we don't know the default branch. In this case cannot determine if
the workflow is running on the default branch, and so cannot know when to enable `cache-read-only`.
Fixes#383
The init-scripts added to Gradle User Home were assuming the presence of certain
GitHub Actions environment variables. With this fix, these init scripts behave
better without these env vars.
Fixes#350
# 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 `build` script in the project root provides a convenient way to perform many local build tasks:
1.`./build` will lint and compile typescript sources
2.`./build all` will lint and compile typescript and run unit tests
3.`./build init-scripts` will run the init-script integration tests
4.`./build act <act-commands>` will run `act` after building local changes (see below)
## Using `act` to run integ-test workflows locally
It's possible to run GitHub Actions workflows locally with https://nektosact.com/.
Many of the test workflows from this repository can be run in this way, making it easier to
test local changes without pushing to a branch.
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.
# Execute Gradle builds in GitHub Actions workflows
# GitHub Actions for Gradle builds
This GitHub Action can be used to configure Gradle and optionally execute a Gradle build on any platform supported by GitHub Actions.
This repository contains a set of GitHub Actions that are useful for building Gradle projects on GitHub.
## Use the action to setup Gradle
## The `setup-gradle` action
If you have an existing workflow invoking Gradle, you can add an initial "Setup Gradle" Step to benefit from caching,
build-scan capture and other features of the gradle-build-action.
The `setup-gradle` action can be used to configure Gradle for optimal execution on any platform supported by GitHub Actions.
All subsequent Gradle invocations will benefit from this initial setup, via `init` scripts added to the Gradle User Home.
This replaces the previous `gradle/gradle-build-action`, which now delegates to this implementation.
The recommended way to execute any Gradle build is with the help of the [Gradle Wrapper](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.
### Example usage
```yaml
name:Run Gradle on PRs
on:pull_request
name:Build
on:
push:
jobs:
gradle:
strategy:
matrix:
os:[ubuntu-latest, macos-latest, windows-latest]
runs-on:${{ matrix.os }}
build:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v3
- uses:actions/setup-java@v3
- name:Checkout sources
uses:actions/checkout@v4
- name:Setup Java
uses:actions/setup-java@v4
with:
distribution:temurin
java-version:11
distribution:'temurin'
java-version:17
- name:Setup Gradle
uses:gradle/gradle-build-action@v2
- name:Execute Gradle build
uses:gradle/actions/setup-gradle@v3
- name:Build with Gradle
run:./gradlew build
```
## Why use the `gradle-build-action`?
See the [full action documentation](docs/setup-gradle.md) for more advanced usage scenarios.
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 `dependency-submission` action
However, the `gradle-build-action` offers a number of advantages over this approach:
Generates and submits a dependency graph for a Gradle project, allowing GitHub to alert about reported vulnerabilities in your project dependencies.
- Easily [run the build with different versions of Gradle](#download-install-and-use-a-specific-gradle-version) using the `gradle-version` parameter. Gradle distributions are automatically downloaded and cached.
- 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).
- Detailed reporting of cache usage and cache configuration options allow you to [optimize the use of the GitHub actions cache](#optimizing-cache-effectiveness).
- [Automatic capture of build scan links](#build-scans) from the build, making these easier to locate for workflow run.
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.
The `gradle-build-action` is designed to provide these benefits with minimal configuration.
These features work both when Gradle is executed via the `gradle-build-action` and for any Gradle execution in subsequent steps.
When using `gradle-build-action` we recommend that you _not_ use `actions/cache` or `actions/setup-java@v3` to explicitly cache the Gradle User Home. Doing so may interfere with the caching provided by this action.
## Use 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.
Simply add this as a new workflow file to your repository (eg `.github/workflows/dependency-submission.yml`).
```yaml
- uses:gradle/gradle-build-action@v2
with:
gradle-version:6.5
```
name:Dependency Submission
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:
```yaml
name:Test latest Gradle RC
on:
schedule:
- cron:00***# daily
push:
branches:['main']
permissions:
contents:write
jobs:
gradle-rc:
dependency-submission:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v3
- uses:actions/setup-java@v3
- name:Checkout sources
uses:actions/checkout@v4
- name:Setup Java
uses:actions/setup-java@v4
with:
distribution:temurin
java-version:11
- uses:gradle/gradle-build-action@v2
with:
gradle-version:release-candidate
- run:gradle build --dry-run# just test build configuration
distribution:'temurin'
java-version:17
- name:Generate and submit dependency graph
uses:gradle/actions/dependency-submission@v3
```
## Gradle Execution
See the [full action documentation](docs/dependency-submission.md) for more advanced usage scenarios.
If the action is configured with an `arguments` input, then Gradle will execute a Gradle build with the arguments provided.
## The `wrapper-validation` action
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.
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`.
### Example workflow
```yaml
name:Run Gradle on PRs
on:pull_request
name:"Validate Gradle Wrapper"
on:
push:
pull_request:
jobs:
gradle:
strategy:
matrix:
os:[ubuntu-latest, macos-latest, windows-latest]
runs-on:${{ matrix.os }}
steps:
- uses:actions/checkout@v3
- 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.
## Caching
By default, this action aims to cache any and all reusable state that may be speed up a subsequent build invocation.
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 ;
- Any [configuration-cache](https://docs.gradle.org/nightly/userguide/configuration_cache.html) data stored in the project `.gradle` directory. (Only supported for Gradle 7 or higher.)
To reduce the space required for caching, this action makes a best effort to reduce duplication in cache entries.
Caching is enabled by default. You can disable caching for the action as follows:
```yaml
cache-disabled:true
```
### Cache keys
Distributions downloaded to satisfy a `gradle-version` parameter are stored outside of Gradle User Home and cached separately. The cache key is unique to the downloaded distribution and will not change over time.
The state of the Gradle User Home and configuration-cache are highly dependent on the Gradle execution, so the cache key is composed of the current commit hash and the GitHub actions job id.
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.
To reduce duplication between cache entries, certain artifacts are cached independently based on their identity.
Artifacts that are cached independently include downloaded dependencies, downloaded wrapper distributions and generated Gradle API jars.
For example, this means that all jobs executing a particular version of the Gradle wrapper will share common entries for wrapper distributions and for generated Gradle API jars.
### Using the caches 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
# 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.
As well as any wrapper distributions, the action will attempt to save and restore the `caches` and `notifications` directories from Gradle User Home.
The contents to be cached can be fine tuned by including and excluding certain paths with 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 from the directories cached.
gradle-home-cache-excludes:|
caches/build-cache-1
```
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.
### Cache debugging and analysis
Gradle User Home state will be restored from the cache during the first `gradle-build-action` step for any workflow job.
This state will be saved back to the cache at the end of the job, after all Gradle executions have completed.
A report of all cache entries restored and saved is printed to the action log when saving the cache entries.
This report can provide valuable insignt 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.
### Optimizing cache effectiveness
Cache storage space for GitHub actions is limited, and writing new cache entries can trigger the deletion of exising 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.
#### Select branches that should write to the cache
GitHub cache entries are not shared between builds on different branches. This means that identical cache entries will be stored separately for different branches.
An exception to this is that cache entries for the default (`master`/`main`) branch can be read by actions invoked for other branches.
By default, the `gradle-build-action` will only _write_ to the cache for builds run on the default 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 caches read-only](#using-the-caches-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
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 you can selectively [exclude content using `gradle-home-cache-exclude`](#gradle-user-home-cache-tuning).
## Saving build outputs
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:
validation:
name:"Validation"
runs-on:ubuntu-latest
steps:
- name:Checkout project sources
uses:actions/checkout@v3
- 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
with:
name:build-reports
path:build/reports/
- uses:actions/checkout@v4
- uses:gradle/actions/wrapper-validation@v3
```
## Build scans
If your build publishes a [build scan](https://gradle.com/build-scans/) the `gradle-build-action` action will:
- Add a notice with the link to the GitHub Actions user interface
- For each step that executes Gradle, adds the link to the published build scan as a Step output named `build-scan-url`.
You can then use that link in subsequent actions of your workflow. For example:
- 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. `3.0.0` → `3.0.1`)
- If new features have been added, bump the minor version (eg `3.1.1` → `3.2.0`)
- If a new major release is required, bump the major version (eg `3.1.1` → `4.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 `v3.1.0`
- From CLI: `git tag v3.1.0 && git push --tags`
- 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 `v3` 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 -a -m "v3.0.0" v3 v3.0.0 && git push -f --tags`
- Note that we set the commit message for the tag to the newly released version.
## Release gradle/gradle-build-action
During the 3.x release series, we will continue to publish parallel releases of `gradle/gradle-build-action`. These releases will simply delegate to `gradle/actions/setup-gradle` with the same version.
- Update the [gradle-build-action action.yml](https://github.com/gradle/gradle-build-action/blob/main/action.yml#L162) file to point to the newly released version of `gradle/actions/setup-gradle`.
- Ensure that any parameters that have been added to the setup-gradle action are added to the gradle-build-action definition, and that these are passed on to setup-gradle.
- Create and push a tag for the release.
- From CLI: `git tag v3.1.0 && git push --tags`
- Go to https://github.com/gradle/gradle-build-action/releases and "Draft new release"
- Use the newly created tag and copy the tag name exactly as the release title.
- In the release notes, point users to the gradle/actions release. Include a header informing users to switch to `gradle/actions/setup-gradle`.
- Publish the release.
- Force push the `v3` tag (or current major version) to point to the new release.
- From CLI: `git tag -f -a -m "v3.0.0" v3 v3.0.0 && git push -f --tags`
## Release gradle/wrapper-validation-action
During the 3.x release series, we will continue to publish parallel releases of `gradle/wrapper-validation-action`. These releases will simply delegate to `gradle/actions/wrapper-validation` with the same version.
- Update the [wrapper-validation-action action.yml](https://github.com/gradle/wrapper-validation-action/blob/main/action.yml#L162) file to point to the newly released version of `gradle/actions/wrapper-validation`.
- Ensure that any parameters that have been added to the `wrapper-validation` action (if any) are added to the action definition, and that these are passed on to setup-gradle.
- Create and push a tag for the release.
- From CLI: `git tag v3.1.0 && git push --tags`
- Go to https://github.com/gradle/wrapper-validation-action/releases and "Draft new release"
- Use the newly created tag and copy the tag name exactly as the release title.
- In the release notes, point users to the gradle/actions release. Include a header informing users to switch to `gradle/actions/wrapper-validation`.
- Publish the release.
- Force push the `v3` tag (or current major version) to point to the new release.
- From CLI: `git tag -f -a -m "v3.0.0" v3 v3.0.0 && git push -f --tags`
## 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 v2.1.4 update PR](https://github.com/actions/starter-workflows/pull/1489) 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 v2.1.4 update PR](https://github.com/github/docs/pull/16392) 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
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
arguments:
description:Gradle command line arguments (supports multi-line input)
required:false
build-root-directory:
description:Path to the root directory of the build
required:false
gradle-executable:
description:Path to the Gradle executable
required:false
generate-job-summary:
description:When 'false', no Job Summary will be generated for the Job.
required:false
default:true
# 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) }}
outputs:
build-scan-url:
description:Link to the build scan if any
name:Build with Gradle
description:A collection of actions for building Gradle projects, as well as generating a dependency graph via Dependency Submission.
runs:
using:'node16'
main:'dist/main/index.js'
post:'dist/post/index.js'
using:"composite"
steps:
- 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
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
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
# 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 and submitted.
Valid values are:
'generate-and-submit' (default): Generates a dependency graph for the project and submits it in the same Job.
'generate-and-upload': Generates a dependency graph for the project and saves it as a workflow artifact.
'download-and-submit': Retrieves a previously saved dependency-graph and submits it to the repository.
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-and-submit'
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
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
default:1
# 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
# DEPRECATED ACTION INPUTS
build-scan-terms-of-service-url:
description:The URL to the Build Scan® terms of use. This input must be set to 'https://gradle.com/terms-of-service'.
required:false
deprecation-message:The input has been renamed to align with the Develocity API. Use 'build-scan-terms-of-use-url' instead.
build-scan-terms-of-service-agree:
description:Indicate that you agree to the Build Scan® terms of use. This input value must be "yes".
required:false
deprecation-message:The input has been renamed to align with the Develocity API. Use 'build-scan-terms-of-use-agree' instead.
generate-job-summary:
description:When 'false', no Job Summary will be generated for the Job.
required:false
default:true
deprecation-message:Superceded by the new 'add-job-summary' and 'add-job-summary-as-pr-comment' parameters.
# 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
Implementing a `dependency-submission` workflow for your repository is documented in the
[core documentation](dependency-submission.md).
But getting it working is the easy part: the dependency alerts you recieve can be confusing and surprising.
Here are some common questions answered.
### How can I easily try this out without experimenting on my main repository?
The https://github.com/gradle/github-dependency-submission-demo repository is setup as a tutorial for you to fork and play with.
### How can I tell if the `dependency-submission` action is working?
Inspect the Dependency Graph for your project (Insights -> Dependency Graph). You should see some dependencies annotated with "Detected by GitHub Dependency Graph Gradle Plugin"
### Why is `(Maven)` stated for all dependencies submitted by this action? I'm not using Maven.
This simply indicates that the dependency was resolved from a standard Gradle/Maven artifact repository. It does not imply which build tool is used.
### Why is every dependency attributed to `settings.gradle.kts`?
All dependendies detected by the `dependency-submission` action are attributed to the Gradle project as a whole. We found that the best way is to link to the project `Settings` file.
We do not currently attempt to attribute dependencies to the actual file where they were declared.
### Why aren't dependencies be linked to the source file where they are declared?
There are a couple of reasons for this:
1. Gradle doesn't currently provide a mechanism to determine the location where a dependency is declared. In fact, the resulting dependency version can be influenced by many different sources within a Gradle project.
2. The GitHub Dependency Graph was modelled heavily on NPM and doesn't really map well to having multiple source locations for a single dependency declaration.
We have long-term plans to improve the first point, and we are working with GitHub to resolve the second. However, at this stage the behaviour your are experiencing is what is expected.
### My repository dependency graph contains a dependency that isn't anywhere in my build. Why is the `dependency-submission` action reporting dependencies I'm not using?
If you see a particular dependency version reported in the dependency graph, it means your build is resolving that dependency at some point.
You may be surprised what transitive dependencies are brought in by declared dependencies and applied plugins in your build.
[See here for a HOW-TO](dependency-submission.md#resolving-a-dependency-vulnerability) on getting the bottom of why the dependency is being resolved.
### I see multiple versions of the same dependency in the dependency graph, but I'm only declaring a single version in my build. Why is the action reporting dependency versions I'm not using?
This is almost certainly because the dependency in question is actually being resolved with different versions in different dependency configurations.
For example, you may have one version brought in as a plugin dependency (resolved in the `classpath` configuration) and another used directly as a code dependency (resolved in the `compileClasspath` configuration).
[See here for a HOW-TO](dependency-submission.md#resolving-a-dependency-vulnerability) on getting the bottom of why the dependency is being resolved.
By far the easiest way is to publish a Build Scan® for the workflow run: [this is easily achieved with some additional action configuration](dependency-submission.md#publishing-a-develocity-build-scan-from-your-dependency-submission-workflow).
### I'm not seeing any security vulnerabilities for any of my dependencies. How can I be sure this is working?
First check that [Dependabot Alerts](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) are enabled for your repository.
Without this, your dependency graph may be populated but you won't see which dependencies are potentially vulnerable.
### How can I use Dependabot Security Updates to generate a PR to update my vulnerable dependencies?
In most cases, the Dependabot Security Updates feature is not able to automatically generate a PR to update a dependency version.
This can be due to the vulnerable dependency being transitive, or because the Dependabot implementation doesn't understand how to update the dependency version.
In a few select cases the Dependabot security update will work and successfully generate a pull-request. For example when a direct dependency version is listed in a TOML dependency catalog.
### I'm getting many false positive Dependabot Alerts for dependencies that aren't used by my project. Why are these dependencies being reported?
The `dependency-submission` action resolves all of the dependencies in your build. This includes plugins, dependencies you've declared, test dependencies, and all transitive dependencies of these.
It doesn't matter how the dependencies are declared: the ones being resolved by Gradle are the ones being reported.
Many people are surprised to see what dependencies are actually being resolved when they run their builds, but I'm yet to see a case where the dependencies being reported are actually incorrect.
Please [follow the instructions here](dependency-submission.md#finding-the-source-of-a-dependency-vulnerability) to identify the source of the dependency version that is being reported.
Once you have worked out why it is being resolved, you can either [update the dependency version](dependency-submission.md#updating-the-dependency-version)
or [exclude it from the submitted dependency graph](dependency-submission.md#limiting-the-dependencies-that-appear-in-the-dependency-graph).
The `gradle/actions/dependency-submission` action provides the simplest (and recommended) way to generate a
dependency graph for your project. This action will attempt to detect all dependencies used by your build
without building and testing the project itself.
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 submitted to your repository via the
If you're confused by the behaviour you're seeing or have specific questions, please check out [the FAQ](dependency-submission-faq.md) before raising an issue.
## General usage
The following workflow will generate a dependency graph for a Gradle project and submit it immediately to the repository via the
Dependency Submission API. For most projects, this default configuration should be all that you need.
Simply add this as a new workflow file to your repository (eg `.github/workflows/dependency-submission.yml`).
```yaml
name:Dependency Submission
on:
push:
branches:['main']
permissions:
contents:write
jobs:
dependency-submission:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v4
- uses:actions/setup-java@v4
with:
distribution:temurin
java-version:17
- name:Generate and submit dependency graph
uses:gradle/actions/dependency-submission@v3
```
### Gradle execution
To generate a dependency graph, the `dependency-submission` action must perform a Gradle execution that resolves
the dependencies of the project. All dependencies that are resolved in this execution will be included in the
generated dependency graph. By default action executes a built-in task that is designed to resolve all build dependencies
In this example, we are searching for dependencies matching the name 'com.squareup.okio:okio' in the _Build Dependencies_ of
the project. You can easily see that this dependency originates from 'com.github.ben-manes:gradle-versions-plugin'.
Knowing the source of the dependency can help determine how to deal with the Dependabot Alert.
Note that you may need to look at both the _Dependencies_ and the _Build Dependencies_ of your project to find the
offending dependency.
### When you cannot publish a Build Scan®
If publishing a free Build Scan to https://scans.gradle.com isn't an option, and you don't have access to a private [Develocity
server](https://gradle.com/) for your project, you can obtain information about the each resolved dependency by running the `dependency-submission` workflow with debug logging enabled.
The simplest way to do so is to re-run the dependency-submission job with debug logging enabled:
When you do so, the Gradle build that generates the dependency-graph will include a log message for each dependency version included in the graph.
Given the details in one log message, you can run (locally) the built-in [dependencyInsight](https://docs.gradle.org/current/userguide/viewing_debugging_dependencies.html#dependency_insights) task
to determine exactly how the dependency was resolved.
For example, given the following message in the logs:
## Limiting the dependencies that appear in the dependency graph
By default, the `dependency-submission` action attempts to detect all dependencies declared and used by your Gradle build.
At times it may helpful to limit the dependencies reported to GitHub, to avoid 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
may not be as important as a vulnerability in one of your runtime dependencies.
The `dependency-submission` action provides a convenient mechanism to filter the projects and configurations that
contribute to the dependency graph.
> [!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.
### Excluding certain Gradle projects from the dependency graph
If you do not want the dependency graph to include dependencies from every project in your build,
you can easily exclude certain projects from the dependency extraction process.
To restrict which Gradle subprojects contribute to the report, specify which projects to exclude via a regular expression.
You can provide this value via the `DEPENDENCY_GRAPH_EXCLUDE_PROJECTS` environment variable or system property.
Note that excluding a project in this way only removes dependencies that are _resolved_ as part of that project, and may
not necessarily remove all dependencies _declared_ in that project. If another project depends on the excluded project
then it may transitively resolve dependencies declared in the excluded project: these dependencies will still be included
in the generated dependency graph.
### Excluding certain Gradle configurations from the dependency graph
Similarly to Gradle projects, it is possible to exclude a set of configuration instances from dependency graph generation,
so that dependencies resolved by those configurations are not included.
To restrict which Gradle configurations contribute to the report, specify which configurations to exclude via a regular expression.
You can provide this value via the `DEPENDENCY_GRAPH_EXCLUDE_CONFIGURATIONS` environment variable or system property.
Note that configuration exclusion applies to the configuration in which the dependency is _resolved_ which is not necessarily
the configuration where the dependency is _declared_. For example if you decare a dependency as `implementation` in
a Java project, that dependency will be resolved in `compileClasspath`, `runtimeClasspath` and possibly other configurations.
### Example of project and configuration filtering
For example, if you want to exclude dependencies in the `buildSrc` project, and exclude dependencies from the `testCompileClasspath` and `testRuntimeClasspath` configurations, you would use the following configuration:
```yaml
- name:Generate and submit dependency graph
uses:gradle/actions/dependency-submission@v3
env:
# Exclude all dependencies that originate solely in the 'buildSrc' project
DEPENDENCY_GRAPH_EXCLUDE_PROJECTS:':buildSrc'
# Exclude dependencies that are only resolved in test classpaths
The [GitHub Dependency Graph Gradle Plugin](https://plugins.gradle.org/plugin/org.gradle.github-dependency-graph-gradle-plugin)
has other filtering options that may be useful.
See [the docs](https://github.com/gradle/github-dependency-graph-gradle-plugin?tab=readme-ov-file#filtering-which-gradle-configurations-contribute-to-the-dependency-graph) for details.
# Advance usage scenarios
## 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 with an environment variable.
See [the setup-gradle docs](setup-gradle.md#using-a-custom-plugin-repository) for details.
## Integrating the `dependency-review-action`
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,
by comparing the dependency graph for the pull-request with that of the HEAD commit.
Example of a pull request workflow that executes a build for a pull request and runs the `dependency-review-action`:
```yaml
name:Dependency review for pull requests
on:
pull_request:
permissions:
contents:write
jobs:
dependency-submission:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v4
- uses:actions/setup-java@v4
with:
distribution:temurin
java-version:17
- name:Generate and submit dependency graph
uses:gradle/actions/dependency-submission@v3
- name:Perform dependency review
uses:actions/dependency-review-action@v3
```
## Usage with pull requests from public forked repositories
This `contents: write` permission is [not available for any workflow that is triggered by a pull request submitted from a public forked repository](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token).
This limitation is designed to prevent a malicious pull request from effecting repository changes.
Because of this restriction, we require 2 separate workflows in order to generate and submit a dependency graph:
1. The first workflow runs directly against the pull request sources and will `generate-and-upload` the dependency graph.
2. The second workflow is triggered on `workflow_run` of the first workflow, and will `download-and-submit` the previously saved dependency graph.
***Main workflow file***
```yaml
name:Generate and save dependency graph
on:
pull_request:
permissions:
contents:read# 'write' permission is not available
jobs:
dependency-submission:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v4
- uses:actions/setup-java@v4
with:
distribution:temurin
java-version:17
- name:Generate and save dependency graph
uses:gradle/actions/dependency-submission@v3
with:
dependency-graph:generate-and-upload
```
***Dependent workflow file***
```yaml
name:Download and submit dependency graph
on:
workflow_run:
workflows:['Generate and save dependency graph']
types:[completed]
permissions:
actions:read
contents:write
jobs:
submit-dependency-graph:
runs-on:ubuntu-latest
steps:
- name:Download and submit dependency graph
uses:gradle/actions/dependency-submission@v3
with:
dependency-graph:download-and-submit# Download saved dependency-graph and submit
```
### Integrating `dependency-review-action` for pull requests from public forked repositories
To integrate the `dependency-review-action` into the pull request workflows above, a third workflow file is required.
This workflow will be triggered directly on `pull_request`, but will wait until the dependency graph results are
submitted before the dependency review can complete. The period 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 above PR check workflow to complete.
```yaml
name:dependency-review
on:
pull_request:
permissions:
contents:read
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 `Generate and save dependency graph` and `Download and submit dependency graph` workflows (above) to complete.
# Gradle version compatibility
Dependency-graph generation is compatible with most versions of Gradle >= `5.2`, and is tested regularly against
Gradle versions `5.2.1`, `5.6.4`, `6.0.1`, `6.9.4`, `7.1.1` and `7.6.3`, as well as all patched versions of Gradle 8.x.
A known exception to this is that Gradle `7.0`, `7.0.1` and `7.0.2` are not supported.
See [here](https://github.com/gradle/github-dependency-graph-gradle-plugin?tab=readme-ov-file#gradle-compatibility) for complete compatibility information.
As these actions evolve, certain inputs, behaviour and usages are deprecated for removal.
Deprecated functionality will be fully supported during the current major release, and will be
removed in the next major release.
Users will receive a deprecation warning when they rely on deprecated functionality,
prompting them to update their workflows.
## The action `gradle/gradle-build-action` has been replaced by `gradle/actions/setup-gradle`
The `gradle-build-action` action has evolved, so that the core functionality is now to configure the
Gradle environment for GitHub Actions. For clarity and consistency with other action (eg `setup-java`, `setup-node`), the `gradle-build-action` has been replaced by the `setup-gradle` action.
As of `v3.x`, the `setup-gradle` and `gradle-build-action` actions are functionally identical,
and are released with the same versions.
To convert your workflows, simply replace:
```
uses: gradle/gradle-build-action@v3
```
with
```
uses: gradle/actions/setup-gradle@v3
```
## The action `gradle/wrapper-validation-action` has been replaced by `gradle/actions/wrapper-validation`
To facilitate ongoing development, the `wrapper-validation-action` action implementation has been merged into
the https://github.com/gradle/actions repository, and the `gradle/wrapper-validation-action` has been replaced by the `gradle/actions/wrapper-validation` action.
As of `v3.x`, the `gradle/wrapper-validation-action` and `gradle/actions/wrappper-validation` actions are
functionally identical, and are released with the same versions.
In a future major version (likely `v4.x`) we will stop releasing new versions of `gradle/wrapper-validation-action`:
development and releases will continue in the `gradle/actions/wrapper-validation` action.
To convert your workflows, simply replace:
```
uses: gradle/wrapper-validation-action@v3
```
with
```
uses: gradle/actions/wrapper-validation@v3
```
## Using the action to execute Gradle via the `arguments` parameter is deprecated
The core functionality of the `setup-gradle` (and `gradle-build-action`) actions is to configure your
Gradle environment for GitHub Actions. Once the action has run, any subsequent Gradle executions will
benefit from caching, reporting and other features of the action.
Using the `arguments` parameter to execute Gradle directly is not necessary to benefit from this action.
This input is deprecated, and will be removed in the `v4` major release of the action.
To convert your workflows, replace any steps using the `arguments` parameter with 2 steps: one to `setup-gradle` and another that runs your Gradle build.
For example, given a workflow like this:
```
steps:
- name: Assemble the project
uses: gradle/actions/setup-gradle@v3
with:
arguments: 'assemble'
- name: Run the tests
uses: gradle/actions/setup-gradle@v3
with:
arguments: 'test'
- name: Run build in a subdirectory
uses: gradle/actions/setup-gradle@v3
with:
build-root-directory: another-build
arguments: 'build'
```
Then replace this with a single call to `setup-gradle` together with separate `run` steps to execute your build.
The exact syntax depends on whether or not your project is configured with the [Gradle wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html).
##### Project uses Gradle wrapper
```
- name: Setup Gradle
uses: gradle/actions/setup-gradle@v3
- name: Assemble the project
run: ./gradlew assemble
- name: Run the tests
run: ./gradlew test
- name: Run build in a subdirectory
working-directory: another-build
run: ./gradlew build
```
##### Project doesn't use Gradle wrapper
```
- name: Setup Gradle for a non-wrapper project
uses: gradle/actions/setup-gradle@v3
with:
gradle-version: 8.9
- name: Assemble the project
run: gradle assemble
- name: Run the tests
run: gradle test
- name: Run build in a subdirectory
working-directory: another-build
run: gradle build
```
Using the action in this way gives you more control over how Gradle is executed, while still giving you
all of the benefits of the `setup-gradle` action.
The `arguments` parameter is scheduled to be removed in `setup-gradle@v4`.
Note: if you are using the `gradle-build-action`, [see here](#the-action-gradlegradle-build-action-has-been-replaced-by-gradleactionssetup-gradle) for more details on how to migrate.
## The `build-scan-terms-of-service` input parameters have been renamed
With recent releases of the `com.gradle.develocity` plugin, key input parameters have been renamed.
-`build-scan-terms-of-service-url` is now `build-scan-terms-of-use-url`
-`build-scan-terms-of-service-agree` is now `build-scan-terms-of-use-agree`
The standard URL for the terms of use has also changed to https://gradle.com/help/legal-terms-of-use
These deprecated build-scan parameters are scheduled to be removed in `setup-gradle@v4` and `dependency-submission@v4`.
## The GRADLE_ENTERPRISE_ACCESS_KEY env var is deprecated
Gradle Enterprise has been renamed to Develocity starting from Gradle plugin 3.17 and Develocity server 2024.1.
In v4 release of the action, it will require setting the access key with the `develocity-access-key` input and Develocity 2024.1 at least to generate short-lived tokens.
If those requirements are not met, the `GRADLE_ENTERPRISE_ACCESS_KEY` env var will be cleared out and build scan publication or other authenticated Develocity operations won't be possible.
This GitHub Action can be used to configure Gradle for optimal execution on any platform supported by GitHub Actions.
## Why use the `setup-gradle` action?
It is possible to directly invoke Gradle in your workflow, and the `actions/setup-java@v4` action provides a simple way to cache Gradle dependencies.
However, the `setup-gradle` action offers a several advantages over this approach:
- Easily [configure your workflow to use a specific version of Gradle](#build-with-a-specific-gradle-version) using the `gradle-version` parameter. Gradle distributions are automatically downloaded and cached.
- 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 them easier to locate in workflow runs.
The `setup-gradle` action is designed to provide these benefits with minimal configuration.
These features work both when Gradle is executed via `setup-gradle` and for any Gradle execution in subsequent steps.
## General usage
The `setup-gradle` 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 this action.
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 following examples assume that the Gradle Wrapper has been configured for the project. See [this example](#build-with-a-specific-gradle-version) if your project doesn't use the Gradle Wrapper.
```yaml
name:Run Gradle on every push
on:
push:
jobs:
gradle:
strategy:
matrix:
os:[ubuntu-latest, macos-latest, windows-latest]
runs-on:${{ matrix.os }}
steps:
- uses:actions/checkout@v4
- uses:actions/setup-java@v4
with:
distribution:temurin
java-version:17
- name:Setup Gradle
uses:gradle/actions/setup-gradle@v3
- name:Execute Gradle build
run:./gradlew build
```
## Build with a specific Gradle version
The `setup-gradle` 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 having to download them again later.
```yaml
- name:Setup Gradle 8.5
uses:gradle/actions/setup-gradle@v3
with:
gradle-version:8.5
- name:Build with Gradle 8.5
run:gradle build
```
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:00***# daily
jobs:
gradle-rc:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v4
- uses:actions/setup-java@v4
with:
distribution:temurin
java-version:17
- uses:gradle/actions/setup-gradle@v3
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 `setup-gradle` action will use the GitHub Actions cache to save and restore reusable state that may speed up subsequent build invocations. 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 cached state 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 attempts to reduce duplication in cache entries on a best effort basis.
The state will be restored from the cache during the first `setup-gradle` 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 been 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 `setup-gradle` 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](#select-which-branches-should-write-to-the-cache) for a more detailed explanation.
In some circumstances, it makes sense to change this default and configure a workflow Job to read existing cache entries but not to write changes back.
You can configure read-only caching for `setup-gradle` 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 the 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 actions was disabled due to pre-existing Gradle User Home
If you want to override the default and have the caches of the `setup-gradle` action overwrite existing content in the Gradle User Home, you can set the `cache-overwrite-existing` parameter to `true`:
```yaml
cache-overwrite-existing:true
```
### Saving configuration-cache data
When Gradle is executed with the [configuration-cache](https://docs.gradle.org/current/userguide/configuration_cache.html) enabled, the configuration-cache data is stored
in the project directory, at `<project-dir>/.gradle/configuration-cache`. Due to the way the configuration-cache works, [this file may contain stored credentials and other
secrets](https://docs.gradle.org/release-nightly/userguide/configuration_cache.html#config_cache:secrets), and this data needs to be encrypted to be safely stored in the GitHub Actions cache.
To benefit from configuration caching in your GitHub Actions workflow, you must:
- Execute your build with Gradle 8.6 or newer. This can be achieved directly or via the Gradle Wrapper.
- Enable the configuration cache for your build.
- Generate a [valid Gradle encryption key](https://docs.gradle.org/8.6/userguide/configuration_cache.html#config_cache:secrets:configuring_encryption_key) and save it as a [GitHub Actions secret](https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions).
- Provide the secret key via the `cache-encryption-key` action parameter.
> The configuration cache cannot be saved or restored in workflows triggered by a pull requests from a repository fork.
> This is because [GitHub secrets are not passed to workflows triggered by PRs from forks](https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow).
> This prevents a malicious PR from reading the configuration-cache data, which may encode secrets read by Gradle.
### Incompatibility with other caching mechanisms
When using `setup-gradle` 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.
## 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 or tags. 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 `setup-gradle`, 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 the 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 Job id
- A hash of the Job matrix parameters and the workflow name
- The git SHA for the latest commit
Specifically, the cache key is: `${cache-protocol}-gradle|${runner-os}|${job-id}[${hash-of-job-matrix-and-workflow-name}]-${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, job id, workflow name, matrix, and Git SHA
- The most recent entry saved for the same OS, job id, workflow name, and matrix values
- The most recent entry saved for the same OS and job id
- 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, it writes a new cache entry 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, before 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 `setup-gradle` steps.
There are a several actions you can take if your cache use is less effective due to entry eviction.
At the end of a Job, The `setup-gradle` 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 entirely new "dependencies" entry would be written. (The `setup-gradle` 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.
Some techniques 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 a 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 or tags.
Workflow runs can _only_ restore caches created in either the same branch or the default branch (usually `main`).
This means that each branch will have its own Gradle User Home cache scope, and will not benefit from cache entries written for other (non-default) branches.
By default, The `setup-gradle` action will only _write_ to the cache for builds run on the default (`master`/`main`) branch.
Jobs running on other branches will only read from the cache. In most cases, this is the desired behavior.
This is because Jobs running on other branches will benefit from the cached Gradle User Home from `main`,
without writing private cache entries which could lead to evicting these shared entries.
If you have other long-lived development branches that would benefit from writing to the cache,
you can configure this by disabling the `cache-read-only` action parameter for these branches.
See [Using the cache read-only](#using-the-cache-read-only) for more details.
Note there are some cases where writing cache entries is typically unhelpful (these are disabled by default):
- For `pull_request` triggered runs, the cache scope is limited to the merge ref (`refs/pull/.../merge`) and can only be restored by re-runs of the same pull request.
- For `merge_group` triggered runs, the cache scope is limited to a temporary branch with a special prefix created to validate pull request changes, and won't be available on subsequent Merge Queue executions.
### 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 the 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 the cache
The Gradle User Home directory tends 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.
To avoid this situation, The `setup-gradle` 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, before 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
```
### Disable local build-cache when remote build-cache is available
If you have a remote build-cache available for your build, then it is recommended to do the following:
- Enable [remote build-cache push](https://docs.gradle.org/current/userguide/build_cache.html#sec:build_cache_configure_use_cases) for your GitHub Actions builds
- Disable [local build-cache]() for your GitHub Actions build
As well as reducing the content that needs to be saved to the GitHub Actions cache,
this setup will ensure that your CI builds populate the remote cache and keep the cache entries fresh by reading these entries.
Local builds can then benefit from the remote cache.
## Debugging and Troubleshooting
To debug a failed job, it can be useful to run with [debug logging enabled](https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging).
You can enable debug logging either by:
1. Adding an `ACTIONS_STEP_DEBUG` variable to your repository configuration ([see here](https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging#enabling-step-debug-logging)).
2. By re-running a Job and checking the "Enable debug logging" box ([see here](https://github.blog/changelog/2022-05-24-github-actions-re-run-jobs-with-debug-logging/)).
### Increased logging from Gradle builds
When debug logging is enabled, this action will cause all builds to run with the `--info` and `--stacktrace` options.
This is done by inserting the relevant [Gradle properties](https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_configuration_properties)
at the top of the `${GRADLE_USER_HOME}/gradle.properties` file.
If the additional Gradle logging produced is problematic, you may opt out of this behavior by setting these properties manually in your project `gradle.properties` file:
```properties
# default lifecycle
org.gradle.logging.level=lifecycle
org.gradle.logging.stacktrace=internal
```
### 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.
When debug logging is enabled, more detailed logging of cache operations is included in the GitHub actions log.
This includes a breakdown of the contents of the Gradle User Home directory, which may assist in cache optimization.
## Build reporting
The `setup-gradle` action collects information about any Gradle executions that occur in a workflow, including the root project,
requested tasks, build outcome, and any Build Scan link generated. Details of cache entries read and written are also collected.
These details are compiled into a Job Summary, which is visible in the GitHub Actions UI.
Generation of a Job Summary is enabled by default for all Jobs using The `setup-gradle` action. This feature can be configured
so that a Job Summary is never generated, or so that a Job Summary is only generated on build failure:
```yaml
add-job-summary:'on-failure'# Valid values are 'always' (default), 'never', and 'on-failure'
```
### Adding Job Summary as a Pull Request comment
It is sometimes more convenient to view the results of a GitHub Actions Job directly from the Pull Request that triggered
the Job. For this purpose, you can configure the action so that Job Summary data is added as a Pull Request comment.
```yaml
name:CI
on:
pull_request:
permissions:
pull-requests:write
jobs:
run-gradle-build:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v4
- uses:actions/setup-java@v4
with:
distribution:temurin
java-version:17
- name:Setup Gradle
uses:gradle/actions/setup-gradle@v3
with:
add-job-summary-as-pr-comment:on-failure# Valid values are 'never' (default), 'always', and 'on-failure'
- run:./gradlew build --scan
```
Note that to add a Pull Request comment, the workflow must be configured with the `pull-requests: write` permission.
### Build Scan® link as Step output
As well as reporting all [Build Scan](https://gradle.com/build-scans/) links in the Job Summary,
The `setup-gradle` action makes this link available as an output of any Step that executes Gradle.
The output name is `build-scan-url`. You can then use the build scan link in subsequent actions of your workflow.
### Saving arbitrary build outputs
By default, a GitHub Actions workflow using `setup-gradle` 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:
- uses:actions/checkout@v4
- uses:actions/setup-java@v4
with:
distribution:temurin
java-version:17
- name:Setup Gradle
uses:gradle/actions/setup-gradle@v3
- 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 of custom init-scripts in Gradle User Home
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/gradle-actions.build-result-capture.init.gradle`.
If you are adding any custom init scripts to the `USER_HOME/.gradle/init.d` directory, it may be necessary to ensure these files are applied before `gradle-actions.build-result-capture.init.gradle`.
Since Gradle applies init scripts in alphabetical order, one way to ensure this is via file naming.
## Gradle Wrapper validation
Instead of using the [wrapper-validation action](./wrapper-validation.md) separately, you can enable
wrapper validation directly in your Setup Gradle step.
```yaml
- name:Setup Gradle
uses:gradle/actions/setup-gradle@v3
with:
validate-wrappers:true
```
If you need more advanced configuration, then you're advised to continue using a separate workflow step
with `gradle/actions/wrapper-validation`.
## Support for GitHub Enterprise Server (GHES)
You can use the `setup-gradle` 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
> [!IMPORTANT]
> The simplest (and recommended) way to generate a dependency graph is via a separate workflow
> using `gradle/actions/dependency-submission`. This action will attempt to detect all dependencies used by your build
> without building and testing the project itself.
>
> See the [dependency-submission documentation](dependency-submission.md) for up-to-date documentation.
The `setup-gradle` 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).
### Basic usage
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. |
| `generate-and-submit` | Generate a dependency graph snapshot for each build invocation, and submit these via the Dependency Submission API on completion of the job. |
| `generate-and-upload` | Generate a dependency graph snapshot for each build invocation, saving it as a workflow artifact. |
| `download-and-submit` | Download any previously saved dependency graph snapshots, and submit them via the Dependency Submission API. This can be useful to submit [dependency graphs for pull requests submitted from repository forks](dependency-submission.md#usage-with-pull-requests-from-public-forked-repositories). |
Example of a CI workflow that generates and submits a dependency graph:
```yaml
name:CI build
on:
push:
permissions:
contents:write
jobs:
build:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v4
- uses:actions/setup-java@v4
with:
distribution:temurin
java-version:17
- name:Setup Gradle to generate and submit dependency graphs
uses:gradle/actions/setup-gradle@v3
with:
dependency-graph:generate-and-submit
- name:Run the usual CI build (dependency-graph will be generated and submitted post-job)
run:./gradlew build
```
The `contents: write` permission is required 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-submission.md#usage-with-pull-requests-from-public-forked-repositories).
### Making dependency graph failures cause Job failures
By default, if a failure is encountered when generating or submitting the dependency graph, the action will log the failure as a warning and continue.
This allows your workflow to be resilient to dependency graph failures, in case dependency graph production is a side-effect rather than the primary purpose of a workflow.
If instead, you have a workflow whose primary purpose is to generate and submit a dependency graph, it makes sense for this workflow to fail if the dependency
graph cannot be generated or submitted. You can enable this behavior with the `dependency-graph-continue-on-failure` parameter, which defaults to `true`.
```yaml
# Ensure that the workflow Job will fail if the dependency graph cannot be submitted
- uses:gradle/actions/setup-gradle@v3
with:
dependency-graph:generate-and-submit
dependency-graph-continue-on-failure:false
```
### 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.
The `GRADLE_PLUGIN_REPOSITORY_USERNAME` and `GRADLE_PLUGIN_REPOSITORY_PASSWORD` can be used when the plugin repository requires authentication.
```yaml
jobs:
build:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v4
- uses:actions/setup-java@v4
with:
distribution:temurin
java-version:17
- name:Setup Gradle to generate and submit dependency graphs
uses:gradle/actions/setup-gradle@v3
with:
dependency-graph:generate-and-submit
- name:Run a build, resolving the 'dependency-graph' plugin from the plugin portal proxy
### 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
- uses:actions/setup-java@v4
with:
distribution:temurin
java-version:17
- name:Setup Gradle to generate and submit dependency graphs
uses:gradle/actions/setup-gradle@v3
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.
See the documentation for [dependency-submission](dependency-submission.md) and the
[GitHub Dependency Graph Gradle Plugin](https://github.com/gradle/github-dependency-graph-gradle-plugin?tab=readme-ov-file#filtering-which-gradle-configurations-contribute-to-the-dependency-graph) for details.
### Gradle version compatibility
Dependency-graph generation is compatible with most versions of Gradle >= `5.2`, and is tested regularly against
Gradle versions `5.2.1`, `5.6.4`, `6.0.1`, `6.9.4`, `7.1.1` and `7.6.3`, as well as all patched versions of Gradle 8.x.
A known exception to this is that Gradle `7.0`, `7.0.1`, and `7.0.2` are not supported.
See [here](https://github.com/gradle/github-dependency-graph-gradle-plugin?tab=readme-ov-file#gradle-compatibility) for complete compatibility information.
### 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 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
- name:Generate dependency graph, but only retain artifact for one day
uses:gradle/actions/setup-gradle@v3
with:
dependency-graph:generate
artifact-retention-days:1
```
# Develocity plugin injection
The `setup-gradle` action provides support for injecting and configuring the Develocity 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 Develocity injection
To enable Develocity injection for your build, you must provide the required configuration via inputs.
Here's a minimal example:
```yaml
- name:Setup Gradle
uses:gradle/actions/setup-gradle@v3
with:
develocity-injection-enabled:true
develocity-url:https://develocity.your-server.com
develocity-plugin-version:3.17.5
- name:Run a Gradle build with Develocity injection enabled
run:./gradlew build
```
This configuration will automatically apply `v3.17.5` of the [Develocity Gradle plugin](https://docs.gradle.com/develocity/gradle-plugin/), and publish build scans to https://develocity.your-server.com.
This example assumes that the `develocity.your-server.com` server allows anonymous publishing of build scans.
In the likely scenario that your Develocity server requires authentication, you will also need to pass a valid [Develocity access key](https://docs.gradle.com/develocity/gradle-plugin/#via_environment_variable) taken from a secret:
- name:Run a Gradle build with Develocity injection enabled
run:./gradlew build
env:
DEVELOCITY_INJECTION_ENABLED:true
DEVELOCITY_URL:https://develocity.your-server.com
DEVELOCITY_PLUGIN_VERSION:3.17
```
This access key will be used during the action execution to get a short-lived token and set it to the DEVELOCITY_ACCESS_KEY environment variable.
### Short-lived access tokens
Develocity access keys are long-lived, creating risks if they are leaked. To avoid this, users can use short-lived access tokens to authenticate with Develocity. Access tokens can be used wherever an access key would be used. Access tokens are only valid for the Develocity instance that created them.
If a short-lived token fails to be retrieved (for example, if the Develocity server version is lower than `2024.1`):
- if a `GRADLE_ENTERPRISE_ACCESS_KEY` env var has been set, we're falling back to it with a deprecation warning
- otherwise no access key env var will be set. In that case Develocity authenticated operations like build cache read/write and build scan publication will fail without failing the build.
For more information on short-lived tokens, see [Develocity API documentation](https://docs.gradle.com/develocity/api-manual/#short_lived_access_tokens).
## Configuring Develocity injection
The `init-script` supports several additional configuration parameters that you may find useful. All configuration options (required and optional) are detailed below:
| develocity-url | :white_check_mark: | the URL of the Develocity server |
| develocity-allow-untrusted-server | | allow communication with an untrusted server; set to _true_ if your Develocity instance is using a self-signed certificate |
| develocity-capture-file-fingerprints | | enables capturing the paths and content hashes of each individual input file |
| develocity-enforce-url | | enforce the configured Develocity URL over a URL configured in the project's build; set to _true_ to enforce publication of build scans to the configured Develocity URL |
| develocity-plugin-version | :white_check_mark: | the version of the [Develocity Gradle plugin](https://docs.gradle.com/develocity/gradle-plugin/) to apply |
| develocity-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-plugin-repository-url | | the URL of the repository to use when resolving the Develocity and CCUD plugins; the Gradle Plugin Portal is used by default |
| gradle-plugin-repository-username | | the username for the repository URL to use when resolving the Develocity and CCUD plugins |
| gradle-plugin-repository-password | | the password for the repository URL to use when resolving the Develocity and CCUD plugins; Consider using secrets to pass the value to this variable |
The input parameters can be expressed as environment variables following the relationships outlined in the table below:
- name:Run a Gradle build with Develocity injection enabled with environment variables
run:./gradlew build
env:
DEVELOCITY_INJECTION_ENABLED:true
DEVELOCITY_URL:https://develocity.your-server.com
DEVELOCITY_PLUGIN_VERSION:3.17.5
```
## Publishing to scans.gradle.com
Develocity injection is designed to enable the publishing of build scans to a Develocity instance,
but is also useful for publishing to the public Build Scans instance (https://scans.gradle.com).
To publish to https://scans.gradle.com, you must specify in your workflow that you accept the [Gradle Terms of Use](https://gradle.com/help/legal-terms-of-use).
This 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`.
## The Gradle Wrapper Problem in Open Source
The `gradle-wrapper.jar` is a binary blob of executable code that is checked into nearly
[2.8 Million GitHub Repositories](https://github.com/search?l=&q=filename%3Agradle-wrapper.jar&type=Code).
Searching across GitHub you can find many pull requests (PRs) with helpful titles like 'Update to Gradle xxx'.
Many of these PRs are contributed by individuals outside of the organization maintaining the project.
Many maintainers are incredibly grateful for these kinds of contributions as it takes an item off of their backlog.
We assume that most maintainers do not consider the security implications of accepting the Gradle Wrapper binary from external contributors.
There is a certain amount of blind trust open source maintainers have.
Further compounding the issue is that maintainers are most often greeted in these PRs with a diff to the `gradle-wrapper.jar` that looks like this.

A fairly simple social engineering supply chain attack against open source would be contribute a helpful “Updated to Gradle xxx” PR that contains malicious code hidden inside this binary JAR.
A malicious `gradle-wrapper.jar` could execute, download, or install arbitrary code while otherwise behaving like a completely normal `gradle-wrapper.jar`.
## Solution
We have created a simple GitHub Action that can be applied to any GitHub repository.
This GitHub Action will do one simple task:
verify that any and all `gradle-wrapper.jar` files in the repository match the SHA-256 checksums of any of our official releases.
If any are found that do not match the SHA-256 checksums of our official releases, the action will fail.
Additionally, the action will find and SHA-256 hash all
- Body (at minimum): `See: https://github.com/gradle/actions/wrapper-validation`
From there, you can easily follow the rest of the prompts to create a Pull Request against the project.
## Reporting Failures
If this GitHub action fails because a `gradle-wrapper.jar` doesn't match one of our published SHA-256 checksums,
we highly recommend that you reach out to us at [security@gradle.com](mailto:security@gradle.com).
**Note:**`gradle-wrapper.jar` generated by Gradle 3.3 to 4.0 are not verifiable because those files were dynamically generated by Gradle in a non-reproducible way. It's not possible to verify the `gradle-wrapper.jar` for those versions are legitimate using a hash comparison. You should try to determine if the `gradle-wrapper.jar` was generated by one of these versions before running the build.
If the Gradle version in `gradle-wrapper.properties` is out of this range, you may need to regenerate the `gradle-wrapper.jar` by running `./gradlew wrapper`. If you need to use a version of Gradle between 3.3 and 4.0, you can use a newer version of Gradle to generate the `gradle-wrapper.jar`.
If you're curious and want to explore what the differences are between the `gradle-wrapper.jar` in your possession
and one of our valid release, you can compare them using this online utility: [diffoscope](https://try.diffoscope.org/).
Regardless of what you find, we still kindly request that you reach out to us and let us know.
## Resources
To learn more about verifying the Gradle Wrapper JAR locally, see our
[guide on the topic](https://docs.gradle.org/current/userguide/gradle_wrapper.html#wrapper_checksum_verification).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
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.