Moved reading of all input parameters into a common source: `input-params.ts`.
This centralized all input parameter reads, and allowed an improved implementation
of reading boolean parameters. In particular, the implementation now provides a default
value for a boolean input parameter that isn't declared for an action.
Introducing new actions for the GitHub dependency graph will involve reuse of much of
the action infrastructure. This commit reorganises things a little to facilitate reuse.
The `PluginManager.hasPlugin` method was not detecting the GE plugin when it
was applied during settingsEvaluated.
Switching to `PluginManager.withPlugin` fixes this.
Fixes#626
With Gradle 8.1, the configuration-cache has changed and is now stable.
As a temporary measure, this commit disables save/restore of the configuration-cache
data to avoid issues until we can deal with this change properly.
When configuration-cache is enabled, the invocationId may not be unique, which can result in
mulitple builds writing to the same file. Rather than failing the post-action, we simply
ignore any subsequent build results with the same ID.
Fixes#441
- Includes basic implementation as `CacheCleaner`
- Integration test that checks unused files are removed:
- Downloaded dependencies
- Local build cache entries
- Wrapper distributions
Now that `@actions/cache` provides a env var override, we can remove our
custom configuration for setting the timeout on cache restore operations.
If the env var is NOT set, we continue to override the 60min default with 10mins.
It appears that when restoring the Gradle User Home directory, certain empty
directories are being identified by Node as broken symlinks. This results in
`Error: ENOENT: No such file or directory` when attempting to resolve a Glob pattern.
By using the default behaviour of Globber (followSymbolicLinks && ignoreBrokenLinks),
these bad files no longer cause errors when saving the Gradle User Home to cache.
Fixes#408
The init-scripts added to Gradle User Home were assuming the presence of certain
GitHub Actions environment variables. With this fix, these init scripts behave
better without these env vars.
Fixes#350
Although convenient, the os.homedir() function can return a different value
that the 'user.home' SystemProperty in Java. The latter is used to locate
the Gradle User Home directory.
By switching to use Java to determine the value for 'user.home', we can use
the same process as Gradle to determine Gradle User Home.
Fixes#207
Now that we are stopping all Gradle daemons in the post-job action,
we can allow daemon processes to be re-used across steps in a workflow job.
Fixes#113
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.
The wrapper zip files are redundant, and not required after extraction.
Gradle 7.5+ will delete these automatically, but we delete them for older
versions to avoid caching the wrapper distributions twice.
Sinc the `gradle-home-cache-excludes` parameter does not support
wildcards, we remove them explicitly.
To save space, future versions of Gradle are likely to delete the downloaded distribution
after extracting it. See gradle/gradle#3605 and gradle/gradle#19495.
To cater for this we will now save/restore the extracted distribution rather than the
downloaded zip file.
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.
- 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.
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
