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.
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.
MacOS runners are initialized with a Gradle User Home directory including
the `~/.gradle/notifications` directory. This was causing the action to skip
restoring the Gradle User Home on MacOS.
This fix limits the pre-existing GUH check to the `~/.gradle/caches` directory
which isn't pre-initialized in the runner.
Fixes#155
There may be cases where it a "fresh" cache entry would be beneficial,
for example if the Gradle User Home cache entry grows over time.
This setting would run the build as if no prior cache entry exists.
By default, the action will attempt to restore a Gradle User Home
cache entry from a different set of matrix inputs (or a different Job entirely)
if an existing entry is not found for the current Job (including matrix inputs).
By specifying the experimental `gradle-home-cache-strict-match` parameter, a user
can avoid this fuzzy matching and ensure that a job execution starts with an
empty Gradle User Home if no entry from a prior execution is found.
Instead of using a fallback strategy to locate a configuration-cache entry
based on the current job and git SHA, these entries are now keyed based on their
file content with the keys persisted in the primary Gradle User Home entry.
This removes the chance of having a configuration-cache entry restored that is
incompatible with the restored Gradle User Home state, and makes the logic easier
to understand.
This change involved a fairly major refactor, with the CacheEntryExtractor being
split out from the primary cache implementation, and adding a separate extractor
implementation for configuration-cache.
Previously, the action was restoring/saving the configuration-cache data for each
step that applied the action. In order to support Gradle invocations that are _not_
managed by the action, the configuration-cache restore is now performed in the initial
action step, and save is performed in the final post-action step.
The build root directories are recorded for each invocation via an init script.
Instead of relying on the separate cache implementations to check for the
existence of cached products, we now explicitly track whether or not the execution
is the first time the action has been invoked for a job.
This is a pure refactor, moving from a separate .cache file per bundle to a single cache-metadata.json file describing all bundles. Instead of storing cache metadata in a separate .cache file per artifact bundle, all of the metadata is now stored in a single `.json` file.
This will make it easier to implement more flexible artifact-caching strategies, such as caching each wrapper zip separately.
* Always include cache protocol version in cache key
* Store all cache metadata in a single JSON file
* Rename cache-metadata file and bump protocol version
* Polish and documentation
Instead of passing `--no-daemon` on the command line, the same
functionality is now acheived by writing a gradle.properties file
when initializing Gradle User Home.
- Warn and continue on failure to restore a Gradle distribution from cache
- Warn and continue on failure to save a Gradle distribution to cache
- Extract common functionality for consistent handling of cache failures
Fixes#116
