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.
The `gradle-build-action` test workflows need to write cache entries,
even when run on non-default branches. This change add explicit configuration
to set `cache-read-only: false` when cache writing is required.
The action requires the generated distribution to committed to the 'dist' directory.
During regular development this step causes a number of problems:
- It's easy to forget to add/commit these generated files.
- It's very difficult/impossible to merge/rebase commits that involve generated files
- These file add unnecessary bulk to the git history
With this change, the quick-check workflow will first build the distribution and then
use the generated output for testing. Building and committing these files will only be
required when merging into the 'main' branch.
- Workflow to run all integTest workflows, allowing use of prior cache entries
- Workflow that starts with empty cache
Both of these use workflow_call to combine the existing workflows.
Now that environment variable reads are auto-detected by Gradle 7.4,
we need a different mechanism to check that the configuration cache is
being used successfully.
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.
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.
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
Attempt to capture as much context as possible about the job run
to generate a unique cache key. Unfortunately much of the matrix context
is not available to the action implementation.
This will eliminate cache entries from previous workflow runs, allowing
us to test cache functionality in isolation. If the `CACHE_KEY_SEED` environment
variable is not set, this will have no impact.
