The most common case for validation will be that the wrapper jars are unchanged
from a previous workflow run. In this case, we cache the validated wrapper
checksums to minimise the work required on a subsequent run.
Fixes#172
- Add deprecation warning for `gradle-home-cache-cleanup`
- Change default for `dependency-submission` to `cache-cleanup: on-success`
- Update documentation for changed default
Previously, including RUNNER_OS was enough to prevent leaking incompatible
content between Gradle User Homes. With the introduction of macos-14,
we now need to differentiate between different runner architectures as well.
Fixes#138
Adds new 'cache-cleanup' parameter with 3 settings: 'never', 'on-success' and 'always'.
This gives users more control over whether cache cleanup should occur.
Fixes#71
The checksum values for most wrapper versions are hard-coded into the
action. These known checksum values are first used for validation: only
if none of the known values work do we download checksums.
Previously, we blindly downloaded all of the checksum values in this
case: we now only download the checksums for versions that are not in
our "known" set.
Fixes#171
Gradle 8.8 introduces new features that allow us to avoid using
timestamp manipulation to force the cleanup of the Gradle User Home directory.
This solution is simpler and more robust, but relies on Gradle 8.8+ always being
used for the cache cleanup operation.
Fixes#24
To cleanup Gradle User Home, a Gradle build must be executed.
Newer Gradle versions are able to cleanup the home directories of older versions,
but not vice-versa.
With this change, the latest version of Gradle is automatically provisioned
in order to run Gradle User Home cleanup. This ensures a consistent version of
Gradle is used for cleanup, and fixes#33 where Gradle is not pre-installed on
a custom runner.
- Always fetch a token for every hostname in the access key
- Use any tokens that are successfully fetched
- Retain access key if no tokens can be fetched
Follow up of https://github.com/gradle/actions/pull/224, we now attempt to set both old and new access key env variables to a short lived token.
If a short-lived token cannot be obtained, then:
- DEVELOCITY_ACCESS_KEY is set to an empty string, preventing this from being used.
- GRADLE_ENTERPRISE_ACCESS_KEY is left intact, with a deprecation warning being issued.
The setup-gradle action tries to get a short-lived access token given the supplied Develocity access key.
This key can be passed either with the `DEVELOCITY_ACCESS_KEY` env var or via the `develocity-access-key` input parameter.
If a token can be retrieved, then the `DEVELOCITY_ACCESS_KEY` env var will be set to the token.
Otherwise the `DEVELOCITY_ACCESS_KEY` will be set to a blank string, to avoid a leak.
---------
Co-authored-by: daz <daz@gradle.com>
Improve readability of build scan when requested tasks is very long, as
agreed in #175. HTML diff for each case of job summary is clearer in
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
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>
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.
- 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.
- 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.
