The fix for #383 introduced a bug that caused the post-action to fail when
attemping to resolve `cache-read-only` for scheduled jobs.
This has been fixed with an explicit (rather than implicit) check for 'event.repository != null'.
Fixes#409
For scheduled workflows, we don't know the default branch. In this case cannot determine if
the workflow is running on the default branch, and so cannot know when to enable `cache-read-only`.
Fixes#383
Cache entries _written_ from jobs run on a non-default branch will be private
to other jobs for that branch. When development flow involves working on a
feature branch and then merging into 'main', these branch-private cache
entries can result in eviction of other (shared) cache entries generated
for the default branch.
With this change, we make the recommended setup the default, by running
with `cache-read-only: true` for any jobs run on a non-default branch.
These jobs will be able to read cache entries written from the main branch,
but will not write any cache entries.
Fixes#143
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.
- 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.
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
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
Leaving the `.lock` and `.receipt` files lying around was causing
issues when the actual jar files were not restored. Now the entire
directory will either be missing, or completely restored.
- Do not restore cache when GUH exists
- Include RUNNER_OS in the cache key
- Do not save cache on exact hit
- Only save cache in the final post action
- Log before saving cache
- Cache is separate from (but similar to) the wrapper distribution cache
- New 'distributions-cache-enabled' flag controls caching of all downloaded distributions
(including wrapper distributions)
- Deprecated the 'wrapper-cache-enabled' flag for removal in v2
