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
Although convenient, the os.homedir() function can return a different value
that the 'user.home' SystemProperty in Java. The latter is used to locate
the Gradle User Home directory.
By switching to use Java to determine the value for 'user.home', we can use
the same process as Gradle to determine Gradle User Home.
Fixes#207
Now that we are stopping all Gradle daemons in the post-job action,
we can allow daemon processes to be re-used across steps in a workflow job.
Fixes#113
Improve init scripts and add test coverage
The build-scan-capture init script will now capture results from builds that do not publish a build-scan, with and without the configuration-cache.
Fixes#292
When enabled, the configuration-cache will cause the build to fail when a
`buildFinished` listener is added. Instead, use a BuildService to listen for task
failures and to write the results on build completion.
The `gradle-build-action` test workflows need to write cache entries,
even when run on non-default branches. This change add explicit configuration
to set `cache-read-only: false` when cache writing is required.
Cache entries _written_ from jobs run on a non-default branch will be private
to other jobs for that branch. When development flow involves working on a
feature branch and then merging into 'main', these branch-private cache
entries can result in eviction of other (shared) cache entries generated
for the default branch.
With this change, we make the recommended setup the default, by running
with `cache-read-only: true` for any jobs run on a non-default branch.
These jobs will be able to read cache entries written from the main branch,
but will not write any cache entries.
Fixes#143
- Bump typescript from 4.7.2 to 4.7.3
- Bump ts-jest from 28.0.3 to 28.0.4
- Added @types/jest which is now required
- Bump eslint from 8.16.0 to 8.17.0
Using `settingsEvaluated` meant that the project root was not recorded
when the build was run with a config-cache hit. This meant that the subsequent
build would not restore the config-cache, resulting in a cache miss.
In order to avoid issues running the init script on older versions of Gradle
the project-collection is extracted into a separate groovy file that is only
applied conditionally on Gradle 7 or higher.
Various improvements to CI workflows
- Compose all integ-test workflow executions into a single calling workflow
- Added a 'quick-check' workflow that provides faster feedback on branches other than main
- Only runs on ubuntu-latest
- Reuses cache entries from previous runs
- Builds distribution outputs so that these don't need to be committed during everyday development
- Added a workflow for purging old workflow executions
Together with the fix for #293, these changes fix#291
The action requires the generated distribution to committed to the 'dist' directory.
During regular development this step causes a number of problems:
- It's easy to forget to add/commit these generated files.
- It's very difficult/impossible to merge/rebase commits that involve generated files
- These file add unnecessary bulk to the git history
With this change, the quick-check workflow will first build the distribution and then
use the generated output for testing. Building and committing these files will only be
required when merging into the 'main' branch.
- Workflow to run all integTest workflows, allowing use of prior cache entries
- Workflow that starts with empty cache
Both of these use workflow_call to combine the existing workflows.
- Bump @actions/cache from 2.0.4 to 2.0.5
- Bump ts-jest from 28.0.2 to 28.0.3
- Bump typescript from 4.6.4 to 4.7.2
- Bump @vercel/ncc from 0.33.4 to 0.34.0
# This Action will scan dependency manifest files that change as part of a Pull Request, surfacing known-vulnerable versions of the packages declared or updated in the PR. Once installed, if the workflow run is marked as required, PRs introducing known-vulnerable packages will be blocked from merging.
# Public documentation: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#dependency-review-enforcement
# 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.
This replaces the previous `gradle/gradle-build-action`, which now delegates to this implementation.
All subsequent Gradle invocations will benefit from this initial setup, via `init` scripts added to the Gradle User Home.
### 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@v2
- uses:actions/setup-java@v2
with:
distribution:temurin
java-version:11
- name:Checkout sources
uses:actions/checkout@v4
- 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](setup-gradle/README.md) for more advanced usage scenarios.
It is possible to directly invoke Gradle in your workflow, and the `actions/setup-java@v2` 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@v2` 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.
on:[push ]
Moreover, you can use the following aliases:
permissions:
contents:write
| 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
jobs:
gradle-rc:
dependency-submission:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v2
- uses:actions/setup-java@v2
with:
java-version:11
- uses:gradle/gradle-build-action@v2
with:
gradle-version:release-candidate
- run:gradle build --dry-run# just test build configuration
- name:Checkout sources
uses:actions/checkout@v4
- name:Generate and submit dependency graph
uses:gradle/actions/dependency-submission@v3
```
## Gradle Execution
If the action is configured with an `arguments` input, then Gradle will execute a Gradle build with the arguments provided.
If no `arguments` are provided, the action will not execute Gradle, but will still cache Gradle state and configure build-scan capture for all subsequent Gradle executions.
```yaml
name:Run Gradle on PRs
on:pull_request
jobs:
gradle:
strategy:
matrix:
os:[ubuntu-latest, macos-latest, windows-latest]
runs-on:${{ matrix.os }}
steps:
- uses:actions/checkout@v2
- uses:actions/setup-java@v2
with:
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 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.
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
In some circumstances, it makes sense for a Gradle invocation to read any existing cache entries but not to write changes back.
For example, you may want to write cache entries for builds on your `main` branch, but not for any PR build invocations.
You can enable read-only caching for any of the caches as follows:
```yaml
# Only write to the cache for builds on the 'main' branch.
# 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.
#### Only write to the cache from the default branch
GitHub cache entries are not shared between builds on different branches. This means that identical cache entries will be stored separately for different branches.
The exception to the is cache entries for the default (`master`/`main`) branch can be read by actions invoked for other branches.
An easy way to reduce cache usage when you run builds on many different branches is to only permit your default branch to write to the cache,
with all other branch builds using `cache-read-only`. 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:
runs-on:ubuntu-latest
steps:
- name:Checkout project sources
uses:actions/checkout@v2
- 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/
```
## 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:
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
# 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!
cache-write-only:
description:When 'true', entries will not be restored from the cache but will be saved at the end of the Job. This allows a 'clean' cache entry to be written.
required:false
default:false
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'."
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 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 to 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 to 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
jobs:
build:
runs-on:ubuntu-latest
steps:
- name:Checkout sources
uses:actions/checkout@v4
- 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.
Do so by setting the `GRADLE_PLUGIN_REPOSITORY_URL` environment variable.
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:
- name:Checkout sources
uses:actions/checkout@v4
- name:Generate and submit dependency graph
uses:gradle/actions/dependency-submission@v3
dependency-review:
needs:dependency-submission
runs-on:ubuntu-latest
steps:
- name:Perform dependency review
uses:actions/dependency-review-action@v3
```
Note that the `dependency-submission` action submits the dependency graph at the completion of the workflow Job.
For this reason, the `dependency-review-action` must be executed in a dependent job, and not as a subsequent step in the job that generates the dependency graph.
## 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:
- name:Checkout sources
uses:actions/checkout@v4
- 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:
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.
description:Generates a dependency graph for a Gradle project and submits it via the Dependency Submission API
inputs:
gradle-version:
description:|
Gradle version to use. If specified, this Gradle version will be downloaded, added to the PATH and used for invoking Gradle.
If not provided, it is assumed that the project uses the Gradle Wrapper.
required:false
build-root-directory:
description:Path to the root directory of the build. Default is the root of the GitHub workspace.
required: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
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'
additional-arguments:
description:|
Additional arguments to pass to Gradle. For example, `--no-configuration-cache --stacktrace`.
required:false
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-service-url` and 'build-scan-terms-of-service-agree'.
required:false
default:false
build-scan-terms-of-service-url:
description:The URL to the Build Scan® terms of service. This input must be set to 'https://gradle.com/terms-of-service'.
required:false
build-scan-terms-of-service-agree:
description:Indicate that you agree to the Build Scan® terms of service. This input value must be "yes".
required:false
runs:
using:"composite"
steps:
- name:Check no setup-gradle
shell:bash
run:|
if [ -n "${GRADLE_BUILD_ACTION_SETUP_COMPLETED}" ]; then
echo "The dependency-submission action cannot be used in the same Job as the setup-gradle action. Please use a separate Job for dependency submission."
// For GHES, this check will take place in ReserveCache API with enterprise file size limit
if (archiveFileSize > fileSizeLimit && !utils.isGhes()) {
@@ -176,8 +180,15 @@ function saveCache(paths, key, options) {
core.debug(`Failed to delete archive: ${error}`);
}
}
- return cacheId;
+ return savedEntry;
});
}
exports.saveCache = saveCache;
+class CacheEntry {
+ constructor(key, size) {
+ this.key = key;
+ this.size = size;
+ }
+}
+exports.CacheEntry = CacheEntry;
//# sourceMappingURL=cache.js.map
\ No newline at end of file
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.
daz