Bumps the gradle group with 1 update in the
/.github/workflow-samples/kotlin-dsl directory:
[com.google.guava:guava](https://github.com/google/guava).
Updates `com.google.guava:guava` from 33.4.5-jre to 33.4.6-jre
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/google/guava/releases">com.google.guava:guava's
releases</a>.</em></p>
<blockquote>
<h2>33.4.6</h2>
<p>Guava 33.4.6 fixes two problems that we introduced while modularizing
Guava in <a
href="https://github.com/google/guava/releases/tag/v33.4.5">33.4.5</a>.</p>
<p>Even if you're not upgrading from Guava 33.4.0 or earlier, still read
<a href="https://github.com/google/guava/releases/tag/v33.4.1">the
release notes for Guava 33.4.1</a>. Those release notes contain
information about Guava 33.4.5 and 33.4.6's effect on the module
system.</p>
<h3>Maven</h3>
<pre lang="xml"><code><dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>33.4.6-jre</version>
<!-- or, for Android: -->
<version>33.4.6-android</version>
</dependency>
</code></pre>
<h3>Jar files</h3>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/33.4.6-jre/guava-33.4.6-jre.jar">33.4.6-jre.jar</a></li>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/33.4.6-android/guava-33.4.6-android.jar">33.4.6-android.jar</a></li>
</ul>
<p>Guava requires <a
href="https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies">one
runtime dependency</a>, which you can download here:</p>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/failureaccess/1.0.3/failureaccess-1.0.3.jar">failureaccess-1.0.3.jar</a></li>
</ul>
<h3>Javadoc</h3>
<ul>
<li><a
href="https://guava.dev/releases/33.4.6-jre/api/docs/">33.4.6-jre</a></li>
<li><a
href="https://guava.dev/releases/33.4.6-android/api/docs/">33.4.6-android</a></li>
</ul>
<h3>JDiff</h3>
<ul>
<li><a
href="https://guava.dev/releases/33.4.6-jre/api/diffs/">33.4.6-jre vs.
33.4.5-jre</a></li>
<li><a
href="https://guava.dev/releases/33.4.6-android/api/diffs/">33.4.6-android
vs. 33.4.5-android</a></li>
<li><a
href="https://guava.dev/releases/33.4.6-android/api/androiddiffs/">33.4.6-android
vs. 33.4.6-jre</a></li>
</ul>
<h3>Changelog</h3>
<ul>
<li>Removed the extra copy of each class from the Guava jar. The extra
copies were an accidental addition from the modularization work in <a
href="https://github.com/google/guava/releases/tag/v33.4.5">Guava
33.4.5</a>. (40485b93ce)</li>
<li>Fixed annotation-related warnings when using Guava in modular
builds. The most common such warning is <code>Cannot find annotation
method 'value()' in type 'DoNotMock': ...</code>. (7e15ab3566)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/google/guava/commits">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The request for a short lived access token fails if the server
certificate is self signed and `develocity-allow-untrusted-server` is
set to true.
I wasn't sure how to write a test for this since nock does not seem to
support mocking a ssl error response.
By inspecting a greater range of build operations for failure, the Job
summary will correctly reflect the build outcome in more circumstances.
Note that we now use the old 'buildFinished' mechanism for all Gradle
versions < `7.0`, instead of using the BuildService mechanism for all
Gradle versions from `6.6`. This avoids needing to deal with
inconsistent build operations present in Gradle versions `[6.6, 7.0)`.
Fixes#415
Automatically generated pull request to update the known wrapper
checksums.
In case of conflicts, manually run the workflow from the [Actions
tab](https://github.com/gradle/actions/actions/workflows/update-checksums-file.yml),
the changes will then be force-pushed onto this pull request branch.
Do not manually update the pull request branch; those changes might get
overwritten.
> [!IMPORTANT]
> GitHub workflows have not been executed for this pull request yet.
Before merging, close and then directly reopen this pull request to
trigger the workflows.
Fixes the Groovy syntax in 2 init-scripts to avoid deprecation warnings.
The fix to the DV injection script is temporary, and will be replaced by
a fix in the upstream reference script.
Fixes#541
Due to an issue with dependency-review-action (https://github.com/gradle/actions/issues/482),
the setup described in the documentation can result in duplicate
dependencies being added to the dependency graph.
To avoid this, we now recommend using a common `dependency-submission`
workflow for both pushes to `main` and pull requests.
The `dependency-review` workflow runs on any `pull_request` but will wait
for the `dependency-submission` to complete.
This setup works for both the standard setup, and for the advanced setup for
pull requests from repository forks.
# Combined PRs ➡️📦⬅️✅ The following pull requests have been successfully combined on this
PR:
- Closes#534 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/kotlin-dsl
- Closes#533 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/java-toolchain
- Closes#532 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/groovy-dsl
- Closes#531 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/gradle-plugin
- Closes#530 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/sources/test/init-scripts
> This PR was created by the
[`github/combine-prs`](https://github.com/github/combine-prs) action
---------
Signed-off-by: bot-githubaction <bot-githubaction@gradle.com>
Co-authored-by: bot-githubaction <bot-githubaction@gradle.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
The cache-cleanup operation works by executing Gradle on a dummy project
and a custom init-script. The version of Gradle used should be at least
as high as the newest version used to run a build.
Previously, if the Gradle version on PATH didn't meet this requirement,
the action would download and install the required Gradle version.
With this PR, the action will now use an existing Gradle wrapper
distribution if it meets the requirement. This avoids unnecessary
downloads of Gradle versions that are already present on the runner.
The logic is:
- Determine the newest version of Gradle that was executed during the
Job. This is the 'minimum version' for cache cleanup.
- Inspect the Gradle version on PATH and any detected wrapper scripts to
see if they meet the 'minimum version'.
- The first executable that is found to meet the requirements will be
used for cache-cleanup.
- If no executable is found that meets the requirements, attempt to
provision Gradle with the 'minimum version'.
Fixes#515
The cache-cleanup operation works by executing Gradle on a dummy project
and a custom init-script. The init-script requires at least Gradle 8.11
to work.
Ideally, the version of Gradle used for cleanup should be no older than
the newest one that wrote entries to Gradle User Home. If an older
Gradle version is used for cache-cleanup, it will not remove entries
written specifically for newer versions.
With this change, we now attempt to ensure that cache-cleanup is run
with the best Gradle version available. We inspect the Gradle version on
PATH to see if it is new enough, otherwise we will provision a Gradle
version equal to the newest one that ran in the Job.
The logic is:
- Determine the newest version of Gradle that was executed during the
Job. This is the 'minimum version' for cache cleanup.
- Inspect the Gradle version on PATH (if any) to see if it is equal to
or newer than the 'minimum version'.
- If the version Gradle on PATH is new enough, use that version for
cache-cleanup.
- If not, attempt to provision Gradle with the 'minimum version'.
Fixes#436
This change primarily impacts test projects and documentation. The only
material impact is that CCUD 2.1 will now be auto-applied when
publishing Build Scans automatically with `build-scan-publish: true`.
(Develocity injection does not hard-code any CCUD version)
Diagnosing unexpected dependencies in the GitHub Dependency Graph can
be difficult. In order to aid with diagnosis, the `dependency-submission`
action will now save each dependency-graph file as a workflow artifact.
If this is undesirable, the prior behaviour can be restored by explicitly setting
`dependency-graph: generate-and-submit`.
Fixes#519
The Gradle build used to perform cache-cleanup will run in the context of init-scripts
provided by the action, including those that collect build-results.
In some circumstances this can lead to unexpected results, such as saving configuration-cache
entries for cache cleanup executions.
With this change, build results will not be captured for cache-cleanup builds.
Previously we were relying on Gradle to substitute JDK environment variables
in toolchains.xml. With this change, the actual path to the JDK is encoded instead.
This should avoid issues where Gradle is not able to successfully resolve the
envioronment variable.
# Combined PRs ➡️📦⬅️✅ The following pull requests have been successfully combined on this
PR:
- Closes#498 Bump Gradle Wrapper from 8.11.1 to 8.12 in
/.github/workflow-samples/kotlin-dsl
- Closes#497 Bump Gradle Wrapper from 8.11.1 to 8.12 in
/.github/workflow-samples/java-toolchain
- Closes#496 Bump Gradle Wrapper from 8.11.1 to 8.12 in
/.github/workflow-samples/groovy-dsl
- Closes#495 Bump Gradle Wrapper from 8.11.1 to 8.12 in
/.github/workflow-samples/gradle-plugin
- Closes#494 Bump Gradle Wrapper from 8.11.1 to 8.12 in
/sources/test/init-scripts
> This PR was created by the
[`github/combine-prs`](https://github.com/github/combine-prs) action
---------
Signed-off-by: bot-githubaction <bot-githubaction@gradle.com>
Co-authored-by: bot-githubaction <bot-githubaction@gradle.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: daz <daz@gradle.com>
Automatically generated pull request to update the known wrapper
checksums.
In case of conflicts, manually run the workflow from the [Actions
tab](https://github.com/gradle/actions/actions/workflows/update-checksums-file.yml),
the changes will then be force-pushed onto this pull request branch.
Do not manually update the pull request branch; those changes might get
overwritten.
> [!IMPORTANT]
> GitHub workflows have not been executed for this pull request yet.
Before merging, close and then directly reopen this pull request to
trigger the workflows.
Co-authored-by: bigdaz <179734+bigdaz@users.noreply.github.com>
Bumps the gradle group with 1 update in the /sources/test/init-scripts
directory:
[com.fasterxml.jackson.dataformat:jackson-dataformat-smile](https://github.com/FasterXML/jackson-dataformats-binary).
Updates `com.fasterxml.jackson.dataformat:jackson-dataformat-smile` from
2.18.1 to 2.18.2
<details>
<summary>Commits</summary>
<ul>
<li><a
href="147bc6024b"><code>147bc60</code></a>
[maven-release-plugin] prepare release
jackson-dataformats-binary-2.18.2</li>
<li><a
href="92648ab980"><code>92648ab</code></a>
Prep for 2.18.2</li>
<li><a
href="d31d695767"><code>d31d695</code></a>
Merge branch '2.17' into 2.18</li>
<li><a
href="a7232c691a"><code>a7232c6</code></a>
Back to snapshot dep</li>
<li><a
href="b362d85402"><code>b362d85</code></a>
[maven-release-plugin] prepare for next development iteration</li>
<li><a
href="d817f53ab6"><code>d817f53</code></a>
[maven-release-plugin] prepare release
jackson-dataformats-binary-2.17.3</li>
<li><a
href="d88c088671"><code>d88c088</code></a>
Prep for 2.17.3</li>
<li><a
href="fa5abd6573"><code>fa5abd6</code></a>
Back to snapshot dep</li>
<li><a
href="d048e2fd91"><code>d048e2f</code></a>
[maven-release-plugin] prepare for next development iteration</li>
<li>See full diff in <a
href="https://github.com/FasterXML/jackson-dataformats-binary/compare/jackson-dataformats-binary-2.18.1...jackson-dataformats-binary-2.18.2">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Automatically generated pull request to update the known wrapper
checksums.
In case of conflicts, manually run the workflow from the [Actions
tab](https://github.com/gradle/actions/actions/workflows/update-checksums-file.yml),
the changes will then be force-pushed onto this pull request branch.
Do not manually update the pull request branch; those changes might get
overwritten.
> [!IMPORTANT]
> GitHub workflows have not been executed for this pull request yet.
Before merging, close and then directly reopen this pull request to
trigger the workflows.
Co-authored-by: bigdaz <179734+bigdaz@users.noreply.github.com>
The build-result-capture.init.gradle script was making some assumptions about
extensions and plugin application that do not apply with the newest GE plugin.
Fixes#449
This test was originally starting with an empty set of checksums,
leading to the download of a checksum for every released and snapshot
version. This resulted in in sporadic test failures.
We now start with a known set of checksums and ensure that those that
are missing are downloaded. This involved some refactoring and
improvement in the way snapshot checksums are processed.
Although we run `setup-gradle` with all/most wrapper files, this global
workflow will ensure that all wrapper files in the repo are valid.
(This should help with the OSSF scorecard)
The cache-cleanup API has changed, so the init-script that worked with
Gradle 8.9 no longer works with 8.11.
We now provision and use Gradle 8.11 for cache cleanup.
This provides a band-aid fix for #417 but that issue will still impact
any build configured to run with Gradle > 8.11
This test assumed that at least one 'snapshot' wrapper checksum was unique,
and not contained in the set of wrapper checksums for released distributions.
This is no longer the case, so the assumption has been modified.
Specifies how the dependency-graph should be handled by this action. By default a dependency-graph will be generated and submitted.
Specifies how the dependency-graph should be handled by this action.
By default a dependency-graph will be generated, submitted to the dependency-submission API, and saved as a workflow artifact.
Valid values are:
'generate-and-submit' (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.
'generate-and-submit': Generates a dependency graph for the project and submits it in the same Job.
'generate-submit-and-upload (default)': As per 'generate-and-submit', but also saves the dependency graph as a workflow artifact.
'generate-and-upload': Generates a dependency graph for the project and saves it as a workflow artifact. Does not submit it to the repository.
'download-and-submit': Retrieves a previously saved dependency-graph and submits it to the repository.
Use `generate-and-submit` if you prefer not to save the dependency-graph as a workflow artifact.
The `generate-and-upload` and `download-and-submit` options are designed to be used in an untrusted workflow scenario,
where the workflow generating the dependency-graph cannot (or should not) be given the `contents: write` permissions
required to submit via the Dependency Submission API.
required:false
default:'generate-and-submit'
default:'generate-submit-and-upload'
dependency-graph-report-dir:
description:|
@@ -147,7 +150,6 @@ inputs:
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.
@@ -295,12 +321,19 @@ The GitHub [dependency-review-action](https://github.com/actions/dependency-revi
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`:
Integrating the Dependency Review Action requires 2 changes to your workflows:
#### 1. Add a `pull_request` trigger to your existing Dependency Submission workflow.
In order to perform Dependency Review on a pull request, the dependency graph must be submitted for the pull request.
To do this, simply add a `pull_request` trigger to your existing dependency submission workflow.
```yaml
name:Dependency review for pull requests
name:Dependency Submission
on:
push:
branches:['main']
pull_request:
permissions:
@@ -318,11 +351,37 @@ jobs:
- name:Generate and submit dependency graph
uses:gradle/actions/dependency-submission@v4
- name:Perform dependency review
uses:actions/dependency-review-action@v4
```
#### 2. Add a dedicated Dependency Review workflow
The Dependency Review 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 up to 10 minutes for dependency submission 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@v4
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 modified dependency-submission workflow to complete.
## 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).
@@ -381,36 +440,6 @@ jobs:
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@v4
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
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.
This setup is designed around [GitHub imposed restrictions on cache access](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache) and should work well in most scenarios.
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.
@@ -196,6 +198,9 @@ When Gradle is executed with the [configuration-cache](https://docs.gradle.org/c
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.
> [!IMPORTANT]
> To avoid potentially leaking secrets in the configuration-cache entry, the action will only save or restore configuration-cache data if the `cache-encryption-key` parameter is set.
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.
Even with everything correctly configured, you may find that the configuration-cache entry is not reused in your workflow.
This is often due to a known issue: [Included builds containing build logic prevent configuration-cache reuse](https://github.com/gradle/actions/issues/21). Refer to the issue for more details.
> [!NOTE]
> 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.
@@ -430,6 +438,15 @@ so that a Job Summary is never generated, or so that a Job Summary is only gener
add-job-summary:'on-failure'# Valid values are 'always' (default), 'never', and 'on-failure'
```
### Excluding specific Gradle builds from Job Summary
The Job Summary works by installing an init-script in Gradle User Home which will record details of any Gradle execution during the workflow.
This means that any Gradle excecution sharing the same Gradle User Home will show up in the Job Summary, which may include Gradle executions
run as part of integration testing.
To avoid having these test builds show up in the Job Summary, add the `GRADLE_ACTIONS_SKIP_BUILD_RESULT_CAPTURE=true` environment variable
to the process that executes Gradle. This will stop the init-script from collecting any build results.
### 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
@@ -502,7 +519,7 @@ jobs:
if:always()
with:
name:build-reports
path:build/reports/
path:**/build/reports/
```
### Use of custom init-scripts in Gradle User Home
@@ -710,20 +727,6 @@ A known exception to this is that Gradle `7.0`, `7.0.1`, and `7.0.2` are not sup
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@v4
with:
dependency-graph:generate
artifact-retention-days:1
```
# Develocity Build Scan® integration
Publishing a Develocity Build Scan can be very helpful for Gradle builds run on GitHub Actions. Each Build Scan provides a
@@ -841,7 +844,7 @@ Here's a minimal example:
run:./gradlew build
```
This configuration will automatically apply `v3.18.1` of the [Develocity Gradle plugin](https://docs.gradle.com/develocity/gradle-plugin/), and publish build scans to https://develocity.your-server.com.
This configuration will automatically apply `v3.19.2` 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:
@@ -907,8 +910,8 @@ Here's an example using the env vars:
@@ -102,7 +102,8 @@ A wrapper jar can fail validation for a few reasons:
1. The wrapper is from a snapshot build of Gradle (nightly or release nightly) and you have not set `allow-snapshots`
or `allow-snapshot-wrappers` to `true`.
2. The wrapper jar is from a version of Gradle with an unverifiable wrapper jar (see below).
3. The wrapper jar was not published by Gradle, and could be compromised.
3. The wrapper jar is saved in Git LFS, and has not been correctly restored on checkout (see below).
4. The wrapper jar was not published by Gradle, and could be compromised.
If this GitHub action fails because a `gradle-wrapper.jar` was not published by Gradle,
we highly recommend that you reach out to us at [security@gradle.com](mailto:security@gradle.com).
@@ -113,6 +114,17 @@ Wrapper Jars generated by Gradle versions `3.3` to `4.0` are not verifiable beca
- If the Gradle version in `gradle-wrapper.properties` is outside of this range, you can regenerate the `gradle-wrapper.jar` by running `./gradlew wrapper`. This will generate a new, verifiable wrapper jar.
- If you need to run your build with a version of Gradle between 3.3 and 4.0, you can use a newer version of Gradle to generate the `gradle-wrapper.jar`.
#### Wrapper Jar stored with Git LFS
If your repository is configured to store Wrapper Jars in Git Large File Storage (LFS), then you must include the configuration to correctly
restore these Jars on checkout. Without this, only a pointer to the Wrapper Jar is restored, and the checksum verification will fail.
```
steps:
- uses: actions/checkout@v4
with:
lfs: true # gradle-wrapper.jar verification will fail without this
```
## Resources
To learn more about verifying the Gradle Wrapper JAR locally, see our
exportconstDEFAULT_READONLY_REASON=`[Cache was read-only](https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#using-the-cache-read-only). By default, the action will only write to the cache for Jobs running on the default branch.`
exportconstDEFAULT_DISABLED_REASON=`[Cache was disabled](https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#disabling-caching) via action confiugration. Gradle User Home was not restored from or saved to the cache.`
exportconstDEFAULT_DISABLED_REASON=`[Cache was disabled](https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#disabling-caching) via action configuration. Gradle User Home was not restored from or saved to the cache.`
exportconstDEFAULT_WRITEONLY_REASON=`[Cache was set to write-only](https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#using-the-cache-write-only) via action configuration. Gradle User Home was not restored from cache.`
@@ -110,10 +110,12 @@ export class CacheEntryListener {
requestedRestoreKeys: string[]|undefined
restoredKey: string|undefined
restoredSize: number|undefined
restoredTime: number|undefined
notRestored: string|undefined
savedKey: string|undefined
savedSize: number|undefined
savedTime: number|undefined
notSaved: string|undefined
constructor(entryName: string){
@@ -130,9 +132,10 @@ export class CacheEntryListener {
`The value '${val}' is not valid for 'dependency-graph'. Valid values are: [disabled, generate, generate-and-submit, generate-and-upload, download-and-submit]. The default value is 'disabled'.`
`The value '${val}' is not valid for 'dependency-graph'. Valid values are: [disabled, generate, generate-and-submit, generate-submit-and-upload, generate-and-upload, download-and-submit].`
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.