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
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 writing the URL to a file on disk, reading it later and
using the Actions API to record the output parameter and write the notice,
these things are now done directly via Actions commands emitted directly
from the init script.
Instead of writing this file to a temp directory and referencing it
on the Gradle command line, the init script is now written to Gradle
User Home so that it is picked up automatically.
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.
Failures to store cache entries should not fail the action or the Job.
This fix attempts to catch and log any unexpected errors that occur when
saving cache entries.
Fixes: #119Fixes: #120
- 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
There's no easy way to get the size of restored/saved cache entries
using the @actions/cache library. Rather than reimplement it, this commit
adds a patch that will be applied whenever 'npm install' is run.
The work is done by 'patch-package'.
Fix issues for 2.0-rc.2
- Support multi-line strings for cache-tuning parameters #106
- Include all downloaded files in `dependencies` bundle #100
- Only restore configuration-cache if Gradle User Home is fully restored #107
Instead of tracking a single 'fully-restored' flag, track the restore status of each
cache entry restore. If any of these are requested but not restored, then the overall
Gradle User Home cache is not fully restored.
Added special handling for the case when zero artifact bundles are set: this is used
in tests to simulate a not-fully-restored state.
Previously, only .jar files were bundled, with other files (modules, POMs, zips, etc)
being left in Gradle User Home. All downloaded files are now included in the bundle.
Fixes#100
The `gradle-home-cache-includes` and `gradle-home-cache-excludes` parameters were initially implemented
as JSON string inputs. This makes these inputs non-idiomatic and easier to get wrong.
This change converts them to multi-line input parameters.
Fixes#106
