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.
Fix Build Scan capture when cache is disabled
With the change to use init-scripts to inject Build Scan capture, this functionality broke when caching was disabled and Gradle User Home wasn't initialized.
This PR fixes a couple of issues and ensures that the Gradle User Home is initialized even when it is not restored from the GitHub Actions cache.
Fixes#138Fixes#139
This change to the integration tests should properly isolate multiple runs of the same job.
Previously, some jobs would fail if you attempted to re-run them via the UI, because the cache
entries would be re-used from the previous run.
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.
- Remove configuration parameter for cache-entry-definitions. This allows richer modelling of extracted entries.
- Include both *.zip and *.tar.gz in entry definition for java-toolchains.
If the user supplies no 'arguments' parameter, the action will function as a
'setup-gradle' action, adding Gradle to the PATH and enabling other features
without actually running a Gradle build.
Any subsequent Gradle invocations in the workflow will benefit from:
- Save/restore of Gradle User Home
- Save/restore of configuration-cache data
- Capture of build-scan URLs
These features are enabled via Gradle User Home, so any Gradle invocation that
uses the same Gradle User Home will be included.
Restore/save configuration-cache data in first action step. This will enable the use of the action for caching without managing all gradle invocations.
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.
Using a single cache entry for all files of a type is necessary to avoid
overloading the cache service. However, this mechanism is not very efficient
for certain artifacts like wrapper zips and generated-gradle-jars, where the
same individual files are often shared between different jobs.
With this change, any configured file patterns that do not end in '*' will
be cached as individual files. At this time this includes downloaded wrapper
zips and generated-gradle-jars.
Fixes#78
