actions/gradle
1
0
Fork 0
mirror of https://github.com/gradle/actions.git synced 2025-11-26 17:09:10 +08:00
Code Issues Packages Projects Releases Wiki Activity

Finish enabling cache-cleanup by default

Browse Source 
- Add deprecation warning for `gradle-home-cache-cleanup`
- Change default for `dependency-submission` to `cache-cleanup: on-success`
- Update documentation for changed default
This commit is contained in:
daz
2024-07-21 13:44:32 -06:00
committed by Daz DeBoer
parent dc97151e55
commit 7bb45b1dbd
6 changed files with 50 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/deprecation-upgrade-guide.md
View File

@@ -148,3 +148,15 @@ These deprecated build-scan parameters are scheduled to be removed in `setup-gra
Gradle Enterprise has been renamed to Develocity starting from Gradle plugin 3.17 and Develocity server 2024.1.
In v4 release of the action, it will require setting the access key with the `develocity-access-key` input and Develocity 2024.1 at least to generate short-lived tokens.
If those requirements are not met, the `GRADLE_ENTERPRISE_ACCESS_KEY` env var will be cleared out and build scan publication or other authenticated Develocity operations won't be possible.
## The `gradle-home-cache-cleanup` input parameter has been replaced by `cache-cleanup`
In versions of the action prior to `v4`, the boolean `gradle-home-cache-cleanup` parameter allows users to opt-in
to cache cleanup, removing unused files in Gradle User Home prior to saving to the cache.
With `v4`, cache-cleanup is enabled by default, and controlled by the `cache-cleanup` input parameter.
To remove this deprecation:
- If you are using `gradle-home-cache-cleanup: true` in your workflow, you can remove this option as this is now enabled by default.
- If you want cache-cleanup to run even when a Gradle build fails, then add the `cache-cleanup: always` input.
- If cache-cleanup is causing problems with your workflow, you can disable it with `cache-cleanup: never`.

37
docs/setup-gradle.md
View File

@@ -153,22 +153,29 @@ In certain circumstances it may be desirable to start with a clean Gradle User H
cache-write-only: true
```
### Enabling cache cleanup
### Configuring cache cleanup
The Gradle User Home directory tends to grow over time. When you switch to a new Gradle wrapper version or upgrade a dependency version
the old files are not automatically and immediately removed. While this can make sense in a local environment, in a GitHub Actions environment
The Gradle User Home directory tends to grow over time. When you switch to a new Gradle wrapper version
or upgrade a dependency version the old files are not automatically and immediately removed.
While this can make sense in a local environment, in a GitHub Actions environment
While this can make sense in a local environment, in a GitHub Actions environment
it can lead to ever-larger Gradle User Home cache entries being saved and restored.
To avoid this situation, The `setup-gradle` action supports the `cache-cleanup` parameter.
When cache-cleanup is enabled, this feature will attempt to delete any files in the Gradle User Home that were not used by Gradle during the GitHub Actions Workflow, before saving the Gradle User Home to the GitHub Actions cache.
To avoid this situation, the `setup-gradle` and `dependency-submission` actions will perform "cache-cleanup",
purging any unused files from the Gradle User Home before saving it to the GitHub Actions cache.
Cache cleanup will attempt to remove any files that are initially restored to the Gradle User Home directory
but that are not used used by Gradle during the GitHub Actions Workflow.
If cache cleanup runs after a failing Gradle build, it is possible that some required files and dependencies will not be touched, and will be removed.
To prevent this scenario, cache cleanup can be configured to run only when all Gradle builds in the Job are successful.
If a Gradle build fails when running the Job, then it is possible that some required files and dependencies
will not be touched during the Job. To prevent these files from being purged, the default behavior is for
cache cleanup to run only when all Gradle builds in the Job are successful.
Gradle Home cache cleanup is considered experimental and is disabled by default. You can enable this feature for the action as follows:
```yaml
cache-cleanup: 'on-success' # Valid values are 'never' (default), 'on-success' and 'always'
```
Gradle Home cache cleanup is enabled by default, and can be controlled by the `cache-cleanup` parameter as follows:
- `cache-cleanup: always`: Always run cache cleanup, even when a Gradle build fails in the Job.
- `cache-cleanup: on-success` (default): Run cache cleanup when the Job contains no failing Gradle builds.
- `cache-cleanup: never`: Disable cache cleanup for the Job.
Cache cleanup will never run when the cache is configured as read-only or disabled.
### Overwriting an existing Gradle User Home
@@ -373,14 +380,6 @@ gradle-home-cache-excludes: |
You can specify any number of fixed paths or patterns to include or exclude.
File pattern support is documented at https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#patterns-to-match-file-paths.
### Remove unused files from Gradle User Home before saving to the cache
The Gradle User Home directory tends to grow over time. When you switch to a new Gradle wrapper version or upgrade a dependency version
the old files are not automatically and immediately removed. While this can make sense in a local environment, in a GitHub Actions environment
it can lead to ever-larger Gradle User Home cache entries being saved and restored.
See [Enabling cache cleanup](#enabling-cache-cleanup) for a mechanism to mitigate this problem.
### Disable local build-cache when remote build-cache is available
If you have a remote build-cache available for your build, then it is recommended to do the following: