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>
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
Instead of always installing and using the latest Gradle version for
cache cleanup, we now require at least Gradle 8.9.
This avoids downloading and installing Gradle if the version on PATH is
sufficient to perform cache cleanup.
The most common case for validation will be that the wrapper jars are unchanged
from a previous workflow run. In this case, we cache the validated wrapper
checksums to minimise the work required on a subsequent run.
Fixes#172
- Add deprecation warning for `gradle-home-cache-cleanup`
- Change default for `dependency-submission` to `cache-cleanup: on-success`
- Update documentation for changed default
Previously, including RUNNER_OS was enough to prevent leaking incompatible
content between Gradle User Homes. With the introduction of macos-14,
we now need to differentiate between different runner architectures as well.
Fixes#138
Adds new 'cache-cleanup' parameter with 3 settings: 'never', 'on-success' and 'always'.
This gives users more control over whether cache cleanup should occur.
Fixes#71
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.
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>
- 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.
