The 'resolveAllDependencies' task is incompatible with project isolation.
Pending a fix to the plugin, disable this feature when running the
dependency-submission action.
Fixes#39
Instead of using 'dependency-graph-action' with some slightly better
values, we now use 'dependency-graph' as the parameter name with a subset
of the options available to 'setup-gradle'.
To prepare for converting the 'dependency-submission' action into Typescript,
we move the 'setup-gradle' entry points and outputs into a sub-directory.
This brings the entire codebase and history of `gradle/gradle-build-action` into
the `gradle/actions` repository, after some modifications to make it easier to
merge.
This will permit the new `gradle/actions/setup-gradle` coordinates to carry on
where `gradle/gradle-build-action` leaves off.
- All NPM sources have been moved into a 'sources' directory
- The main action.yml and README are not located at `setup-gradle`
Bumps the github-actions group with 1 update:
[gradle/gradle-build-action](https://github.com/gradle/gradle-build-action).
Updates `gradle/gradle-build-action` from 2.11.1 to 2.12.0
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/gradle/gradle-build-action/releases">gradle/gradle-build-action's
releases</a>.</em></p>
<blockquote>
<h2>v2.12.0</h2>
<p>Adds a new option to clear a previously submitted
dependency-graph.</p>
<pre lang="yaml"><code>steps:
- uses: gradle/gradle-build-action@v2
with:
dependency-graph: clear
</code></pre>
<p>This may prove useful when migrating to a workflow using the upcoming
<code>gradle/actions/dependency-submission</code> action.</p>
<p><strong>Full-changelog</strong>: <a
href="https://github.com/gradle/gradle-build-action/compare/v2.11.1...v2.12.0">https://github.com/gradle/gradle-build-action/compare/v2.11.1...v2.12.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/gradle/gradle-build-action/commit/a8f75513eafdebd8141bd1cd4e30fcd194af8dfa"><code>a8f7551</code></a>
Build outputs</li>
<li><a
href="https://github.com/gradle/gradle-build-action/commit/9283312acb2f03f47ca40702fbba3a42a81047a2"><code>9283312</code></a>
Add new option to clear dependency-graph</li>
<li><a
href="https://github.com/gradle/gradle-build-action/commit/7c8a278ea037b3ba08ccf2147b8ba80be977578e"><code>7c8a278</code></a>
Remove old clear-dependency-graph action</li>
<li><a
href="https://github.com/gradle/gradle-build-action/commit/d8ca9b7d2e81bf7bfcb000dc25ef59c87acf81e1"><code>d8ca9b7</code></a>
Do full checks on release branches</li>
<li>See full diff in <a
href="https://github.com/gradle/gradle-build-action/compare/v2.11.1...v2.12.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The default JDK on some runners can have minor differences, resulting
in configuration-cache misses. Setting the Java version explicitly should
ensure consistency.
When changing workflow names or when changing to the new 'dependency-submission'
action, it can be useful to clear existing dependency graph snapshots from previous
submissions. While the old graphs will eventually "age out", the 'clear' option will
submit an empty dependency graph for an existing Job correlator, ensuring that old
dependency graphs don't linger.
When using the `@actions/cache` library to save cache entries, it seems that one
or more Promises remain unresolved after the save completes.
With Node20 this causes a delay when exiting the process: the default behaviour
now wait for these Promises to complete. Adding an explicit `Process.exit()`
removes the delay, returning to the Node 16 behaviour.
Fixes#1038
These actions simply delegate to `gradle/gradle-build-action`
- `setup-gradle`: As `gradle-build-action` without the execution capability.
- `dependency-submission`: Submits a dependency graph for the project.
One goal for the original dependency-graph support was to minimize it's
impact on existing workflows, by operating transparently and not
impacting the build outcome. This meant that any failures in
dependency-graph generation or submission were logged as warnings, but
did not cause the workflow to fail.
However, in some cases the primary purpose of a workflow is to generate
and submit a dependency graph: in these cases it is desirable to have
the workflow fail when this process breaks.
This PR introduces a new `dependency-graph-continue-on-failure`
parameter, which when `false` will enable the latter behaviour. It also
adds test coverage for different failures in dependency graph generation
and submission.
Fixes#1034Fixes#997
- Translate to env var for init-script support
- Use when deciding whether to log or rethrow errors
- Add a custom error type to trigger failure in post action
When state is reused from the configuration cache, no dependencies are resolved.
This fix prevents the action from submitting an empty dependency graph in this case.
Since adding these to the `org.gradle.java.installations.fromEnv` property
is problematic (#1024), this mechanism allows the default toolchains to
be discovered by Gradle via a different mechanism.
The default JDK installations are added to `~/.m2/toolchains.xml` such that
they are discoverable by Gradle toolchain support.
The `setup-java` action also writes to this file, so we merge with any existing
content: this allows both pre-installed and "setup" JDKs to be automatically
detected by Gradle.
Previously, the workflow name was always included when matching a cache entry for the current job.
This can be overly restrictive when job definitions are shared between different workflows.
The workflow name is still encoded in the cache entry key, but not in the restore key searching for entries with a matching job.
Fixes#1017
Instead of a binary true/false option, it is now possible to only add
a Job Summary when the build failed. This applies both to the overall
Job Summary added to the workflow run, and to the new PR comment feature.
Rather than requiring a separate step to add a PR comment,
the `gradle-build-action` can now automatically add the Job Summary
as a PR comment
Fixes#1020
- Don't upload artifacts when using 'generate-and-submit'
- New option 'generate-and-upload' to be used with 'download-and-submit'
- Use Artifact API for downloading in the same and different workflow
- Avoid "Entry not saved: reason unknown" when entry was not restored
- Avoid "Entry not saved: Encryption key not provided" when no config-cache data found
- Avoid spurious log message when no config-cache data found
Earlier versions of Gradle didn't support the `GRADLE_ENCRYPTION_KEY`
for the configuration-cache, and so are either not useful to save,
or are actually unsafe due to unencrypted secrets.
We use semver to compare the Gradle version used to produce the config-cache
entry with the minimum Gradle version required.
- Avoid logging "not restoring" message when no entries exist to restore
- Clear the entries from metadata when they are not restored. This ensures that
the non-restored entries are correctly purged.
This makes it easier for users to enable config-cache saving in their workflow.
Config-cache data will only be saved/restored when the key is provided,
and the key is exported as `GRADLE_ENCRYPTION_KEY` for use in subsequent steps.
The `PluginManager` type wasn't introduced until Gradle 2.x.
Remove this type from the method signature in an attempt to allow this
file to be parsed with Gradle 1.12.
The repository URL used to resolve the `github-dependency-graph-gradle-plugin` is now
configurable, allowing a user to specify an internal proxy if the public portal is not available.
Specify a custom plugin repository using the `GRADLE_PLUGIN_REPOSITORY_URL` env var,
or the `gradle.plugin-repository.url` System property.
Fixes#933
* dd/dependency-updates:
Bumps the npm-dependencies group with 5 updates:
Bump the github-actions group with 2 updates
Bump from Gradle 8.4 to Gradle 8.5
- Added a new `artifact-retention-days` input parameter to control retention of uploaded artifacts
- Artifacts retention will use repository settings if not overridden.
A common issue when submitting a dependency graph is that the required
'contents: write' permission is not set.
We now catch any dependency submission failure and inform the user to check
that the required permissions are available.
When using 'download-and-submit' for dependency graphs, we now run the
submission immediately instead of waiting until the post-action.
This allows a single job to both submit the graph and run the dependency
review action.
- Allow environment variables to be overridden by system properties in dependency-graph initscript
- Set `GITHUB_DEPENDENCY_GRAPH_ENABLED=false` when executing Gradle for cache cleanup
In a pull request, GITHUB_SHA is set to the "last merge commit on the GITHUB_REF branch".
This isn't the correct value to use when generating a dependency graph.
This changes to use the value of `pull_request.head.sha`, which is the correct
value for a dependency graph.
Fixes#882
Adds a new init-script which can enable and configure the Gradle Enterprise plugin(s)
for a build, without needing to modify the settings script for the project.
The functionality is enabled and configured via environment variables or system properties.
Not yet wired into `gradle-build-action`.
- Describe the limitations/properties of the GitHub Actions cache
- Document the algorithm for generating a cache key, and the way that cache entries are matched
- Describe in more detail how entries are de-duplicated
- Explain how cache entries can be optimized in Job pipelines
Fixes#831Fixes#608
Users will currently need to spend some time working out the required regex when using `DEPENDENCY_GRAPH_INCLUDE_PROJECTS`. Providing an example will get users up to speed quicker.
Signed-off-by: Andy Coates <[email protected]>
Fixes: #840
With Gradle 8.0.2 (not tried other versions) the configuration name is runtimeClasspath not RuntimeClasspath. Using the latter results in an empty set of dependencies being reported (as it matches no configurations).
Signed-off-by: Andy Coates <[email protected]>
If an existing dependency graph file is present for the configured job correlator,
we now generate a unique correlator value for the invocation. This allows the action
to submit dependency snapshots for a series of Gradle invocations within the same Job.
This commit updates to `[email protected]`, which reduces
redundancy in the mapping of resolved Gradle dependencies to the GitHub Dependency Graph.
Adds a 'dependency-graph' parameter that has 4 options:
1. 'disabled': no dependency graph files generated (the default)
2. 'generate': dependency graph files will be generated and saved as artifacts.
3. 'generate-and-submit': dependency graph files will be generated, saved as artifacts,
and submitted to the Dependency Submission API on job completion.
4. 'download-and-submit': any previously uploaded dependency graph artifacts will be downloaded
and submitted to the Dependency Submission API.
Instead of requiring an action step to generate the graph, configure Gradle User Home
so that subsequent Gradle invocations can generate a graph. Any generated graph files
are uploaded as artifacts on job completion.
- Construct job.correlator from workflow/job/matrix
- Export job.correlator as an environment var
- Upload artifacts at job completion in post-action step
- Specify the location of dependency graph report
- Only apply dependency graph init script when explicitly enabled
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
Logging of the AZURE_LOG_LEVEL env var value is considered a security issue,
since any environment variable value could contain sensitive information.
In this case, logging the value is not really necessary.
The included sourcemap-register.js file is triggering a high priority
CodeQL warning, which can prevent users from adopting the action.
Removing this sourcemap support for now, until this can be fixed upstream.
- Bump eslint from 8.23.0 to 8.23.1
- Bump typescript from 4.8.2 to 4.8.3
- Bump eslint-plugin-jest from 27.0.1 to 27.0.4
- Bump @typescript-eslint/parser from 5.36.2 to 5.37.0
- 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 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
This commit reverts the change in v3.0.0 of @actions/cache, that
causes cache errors to be logged and swallowed. By allowing these
errors to propogate, the action can take appropriate action and
provide useful error messages.
Fixes#407
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
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
Improve init scripts and add test coverage
The build-scan-capture init script will now capture results from builds that do not publish a build-scan, with and without the configuration-cache.
Fixes#292
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.
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
- Bump typescript from 4.7.2 to 4.7.3
- Bump ts-jest from 28.0.3 to 28.0.4
- Added @types/jest which is now required
- Bump eslint from 8.16.0 to 8.17.0
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.
Various improvements to CI workflows
- Compose all integ-test workflow executions into a single calling workflow
- Added a 'quick-check' workflow that provides faster feedback on branches other than main
- Only runs on ubuntu-latest
- Reuses cache entries from previous runs
- Builds distribution outputs so that these don't need to be committed during everyday development
- Added a workflow for purging old workflow executions
Together with the fix for #293, these changes fix#291
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.
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.
- Bump @actions/cache from 2.0.4 to 2.0.5
- Bump ts-jest from 28.0.2 to 28.0.3
- Bump typescript from 4.6.4 to 4.7.2
- Bump @vercel/ncc from 0.33.4 to 0.34.0
Production deps:
- Bump @actions/tool-cache from 1.7.2 to 2.0.1
- Bump @actions/http-client from 1.0.11 to 2.0.1
- Bump @actions/github from 5.0.1 to 5.0.3
- Bump @actions/cache from 2.0.2 to 2.0.4
Dev deps:
- Bump eslint from 8.14.0 to 8.15.0
- Bump eslint-plugin-jest from 26.2.0 to 26.2.2
- Bump jest from 27.5.1 to 28.1.0
- Bump ts-jst from 27.1.4 to 28.0.2
- Remove explicit dependency on jest-circus: this is now the default runner
- Remove test timeout setting
- Remove @types/jest from explicit dependencies
Production deps:
- Bump @actions/core:1.6.0 to 1.8.2
Development deps:
- Bump typescript from 4.6.3 to 4.6.4
- Bump @typescript-eslint/parser from 5.20.0 to 5.23.0
- Bump eslint-plugin-jest from 26.1.4 to 26.2.0
- Switch from deprecated @zeit/ncc to @vercel/ncc
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.
The test Gradle sample apps reference plugins, and it's good to keep these
updated (particularly the GE plugin).
Minor changes to the build scripts were required to satisfy Dependabot.
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.
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
Improves logging for caching, and adds 2 experimental cache options:
- `gradle-home-cache-strict-match`: Avoid re-using a Gradle Home cache entry written by a different job. Only cache entries written by the current Job will be used.
- `cache-write-only`: Do not restore existing cache entries, but still save cache entries in post-action. Fixes#141.
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
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
Add some internal options for fine-tuning the gradle-build-action cache
- Can specify cache-paths to override the default directories cached from Gradle User Home
- Can specify cache-exclude-paths to exclude files from the Gradle User Home cache
- Files under caches/<gradle-version>/kotlin-dsl are now cached as a bundle
Ensure all-or-nothing restore of cached instrumented-jars
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.
Fixes#91
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.
Instead of parsing the log output, we instead register a
buildScanPublished listener and record the build scan URL
to a file. This file is subsequently read to report the
build scan URL.
Fixes#30
When caching is too fine-grained, an excessive number of cache
requests can result in HTTP 429 errors due to rate limiting.
By caching all artifacts of a particular type in a single entry
we hope to mitigate this, at the expense of some reduction in
cache space optimization.
This change also adds caching for all dependency jars, as well as
instrumented jars in the 'caches/jars-X' directory.
Unfortunately, doing this overloads the GitHub actions cache infrastructure
leading to failures and unpredictable results.
A later solution may re-implement artifact sharing for dependency jars
as well as jars within the `caches/jars-9` directory. But for now these
will be duplicated across each Gradle User Home cache entry.
Similar to wrapper distributions, these large files are common
to many Gradle User Home cache entries. Storing them separately removes
this redundancy from the Gradle User Home cache.
In the current model, each cached Gradle User Home could contain
a copy of one or more downloaded wrapper distributions. This results
in large cache entries which could easily lead to premature eviction.
With this change, wrapper dists are cached separately from the rest
of the Gradle User Home directory. The artifact file is replaced by
a marker file which allows the action to restore the artifact from
cache when the Gradle user Home cache is restored.
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.
The Gradle daemon is not useful for ephemeral builds, and the process
can hold file locks which interfere with cache entry generation.
In the case where multiple Gradle invocations occur in the same job,
we could provide a way for users to override this behaviour, taking care
of stopping any daemon process at the end of the job.
- 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 keys have a hard limit of 512 characters, so we need to ensure that we don't generate a key longer than this.
- Remove excess whitespace
- Truncate to 400 characters
Fixes#70
This makes the version alias match other places where we reference a release candidate version.
The 'rc' alias is still supported, but emits a deprecation warning.
- 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
Prior to this change, the wrapper cache contained both the downloaded zip
file as well as the exploded wrapper dir. Only the zip file is required,
as Gradle will automatically detect and unpack.
- Provide a more useful error message when no Gradle wrapper can be located,
and 'gradle-version' or 'gradle-executable' is not used.
- Add test for case where wrapper is missing.
This isn't really a "test" per-se, but this failing build invocation makes it
easy to verify the GitHub action behaviour when the build is misconfigured.
- Remove the 'gradle --stop' step from the prod workflow.
We either need to stop all instances started, or rely on GitHub to clean up processes on completion.
- Remove configuration-cache and dependencies-cache from basic tests. We will later need to add
tests invocations specific for these features.
# This Action will scan dependency manifest files that change as part of a Pull Request, surfacing known-vulnerable versions of the packages declared or updated in the PR. Once installed, if the workflow run is marked as required, PRs introducing known-vulnerable packages will be blocked from merging.
# Public documentation: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#dependency-review-enforcement
# Execute Gradle commands in GitHub Actions workflows
# GitHub Actions for Gradle builds
This GitHub Action can be used to run arbitrary Gradle commands on any platform supported by GitHub Actions.
This repository contains a set of GitHub Actions that are useful for building Gradle projects on GitHub.
You might also be interested by the related [Gradle Plugin](https://github.com/eskatos/gradle-github-actions-plugin) that allows your build to easily get GitHub Actions environment and tag Gradle Build Scans accordingly.
## The `setup-gradle` action
## Usage
This replaces the previous `gradle/gradle-build-action`, which now delegates to this implementation.
The following workflow will run `./gradlew build` using the wrapper from the repository on ubuntu, macos and windows. The only prerequisite is to have Java installed, you can define the version you need to run the build using the `actions/setup-java` action.
### Example usage
```yaml
# .github/workflows/gradle-build-pr.yml
name:Run Gradle on PRs
on:pull_request
name:Build
on:[push ]
jobs:
gradle:
strategy:
matrix:
os:[ubuntu-latest, macos-latest, windows-latest]
runs-on:${{ matrix.os }}
steps:
- uses:actions/checkout@v2
- uses:actions/setup-java@v1
with:
java-version:11
- uses:eskatos/gradle-command-action@v1
with:
arguments:build
```
## Gradle arguments
The `arguments` input can used to pass arbitrary arguments to the `gradle` command line.
Here are some valid examples:
```yaml
arguments:build
arguments:check --scan
arguments:some arbitrary tasks
arguments:build -PgradleProperty=foo
arguments:build -DsystemProperty=bar
....
```
See `gradle --help` for more information.
If you need to pass environment variables, simply use the GitHub Actions workflow syntax:
```yaml
- uses:eskatos/gradle-command-action@v1
env:
CI:true
```
## Run a build from a different directory
```yaml
- uses:eskatos/gradle-command-action@v1
with:
build-root-directory:some/subdirectory
```
## Use a Gradle wrapper from a different directory
```yaml
- uses:eskatos/gradle-command-action@v1
with:
wrapper-directory:path/to/wrapper-directory
```
## Use a specific `gradle` executable
```yaml
- uses:eskatos/gradle-command-action@v1
with:
gradle-executable:path/to/gradle
```
## Setup and use a declared Gradle version
```yaml
- uses:eskatos/gradle-command-action@v1
with:
gradle-version:6.5
```
`gradle-version` can be set to any valid Gradle version.
Moreover, you can use the following aliases:
| Alias | Selects |
| --- |---|
| `wrapper` | The Gradle wrapper's version (default, useful for matrix builds) |
| `current` | The current [stable release](https://gradle.org/install/) |
| `rc` | The current [release candidate](https://gradle.org/release-candidate/) if any, otherwise fallback to `current` |
| `nightly` | The latest [nightly](https://gradle.org/nightly/), fails if none. |
| `release-nightly` | The latest [release nightly](https://gradle.org/release-nightly/), fails if none. |
This can be handy to, for example, automatically test your build with the next Gradle version once a release candidate is out:
```yaml
# .github/workflows/test-gradle-rc.yml
name:Test latest Gradle RC
on:
schedule:
- cron:00***# daily
jobs:
gradle-rc:
build:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v2
- uses:actions/setup-java@v1
with:
java-version:11
- uses:eskatos/gradle-command-action@v1
with:
gradle-version:rc
arguments:build --dry-run# just test build configuration
- name:Checkout sources
uses:actions/checkout@v4
- name:Setup Gradle
uses:gradle/actions/setup-gradle@v3
- name:Build with Gradle
run:./gradlew build
```
## Caching
See the [full action documentation](setup-gradle/README.md) for more advanced usage scenarios.
This action provides 3 levels of caching to help speed up your GitHub Actions:
## The `dependency-submission` action
-`wrapper` caches the local [wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html) installation, saving time downloading and unpacking Gradle distributions ;
-`dependencies` caches the [dependencies](https://docs.gradle.org/current/userguide/dependency_resolution.html#sub:cache_copy), saving time downloading dependencies ;
-`configuration` caches the [build configuration](https://docs.gradle.org/nightly/userguide/configuration_cache.html), saving time configuring the build.
Generates and submits a dependency graph for a Gradle project, allowing GitHub to alert about reported vulnerabilities in your project dependencies.
Only the first one, caching the wrapper installation, is enabled by default.
Future versions of this action will enable all caching by default.
The following workflow will generate a dependency graph for a Gradle project and submit it immediately to the repository via the
Dependency Submission API. For most projects, this default configuration should be all that you need.
You can control which level is enabled as follows:
Simply add this as a new workflow file to your repository (eg `.github/workflows/dependency-submission.yml`).
```yaml
wrapper-cache-enabled:true
dependencies-cache-enabled:true
configuration-cache-enabled:true
```
name:Dependency Submission
The wrapper installation cache is simple and can't be configured further.
on:[push ]
The dependencies and configuration cache will compute a cache key in a best effort manner.
Keep reading to learn how to better control how they work.
permissions:
contents:write
### Configuring the dependencies and configuration caches
Both the dependencies and configuration caches use the same default configuration:
They use the following inputs to calculate the cache key:
```text
**/*.gradle
**/*.gradle.kts
**/gradle.properties
gradle/**
```
This is a good enough approximation.
They restore cached state even if there isn't an exact match.
If the defaults don't suit your needs you can override them with the following inputs:
```yaml
dependencies-cache-key:|
**/gradle.properties
gradle/dependency-locking/**
dependencies-cache-exact:true
configuration-cache-key:|
**/gradle.properties
gradle/dependency-locking/**
configuration-cache-exact:true
```
Coming up with a good cache key isn't trivial and depends on your build.
The above example isn't realistic.
Stick to the defaults unless you know what you are doing.
If you happen to use Gradle [dependency locking](https://docs.gradle.org/current/userguide/dependency_locking.html) you can make the dependencies cache more precise with the following configuration:
If your build publishes a [build scan](https://gradle.com/build-scans/) the `gradle-command-action` action will emit the link to the published build scan as an output named `build-scan-url`.
You can then use that link in subsequent actions of your workflow.
The `gradle/actions/dependency-submission` action provides the simplest (and recommended) way to generate a
dependency graph for your project. This action will attempt to detect all dependencies used by your build
without building and testing the project itself.
The dependency graph snapshot is generated via integration with the [GitHub Dependency Graph Gradle Plugin](https://plugins.gradle.org/plugin/org.gradle.github-dependency-graph-gradle-plugin), and submitted to your repository via the
If publishing a free Build Scan to https://scans.gradle.com isn't an option, and you don't have access to a private [Develocity
server](https://gradle.com/) for your project, you can obtain information about the each resolved dependency by running the `dependency-submission` workflow with debug logging enabled.
The simplest way to do so is to re-run the dependency-submission job with debug logging enabled:
When you do so, the Gradle build that generates the dependency-graph will include a log message for each dependency version included in the graph.
Given the details in one log message, you can run (locally) the built-in [dependencyInsight](https://docs.gradle.org/current/userguide/viewing_debugging_dependencies.html#dependency_insights) task
to determine exactly how the dependency was resolved.
For example, given the following message in the logs:
## Limiting the dependencies that appear in the dependency graph
By default, the `dependency-submission` action attempts to detect all dependencies declared and used by your Gradle build.
At times it may helpful to limit the dependencies reported to GitHub, to avoid security alerts for dependencies that
don't form a critical part of your product. For example, a vulnerability in the tool you use to generate documentation
may not be as important as a vulnerability in one of your runtime dependencies.
The `dependency-submission` action provides a convenient mechanism to filter the projects and configurations that
contribute to the dependency graph.
> [!NOTE]
> Ideally, all dependencies involved in building and testing a project will be extracted and reported in a dependency graph.
> These dependencies would be assigned to different scopes (eg development, runtime, testing) and the GitHub UI would make it easy to opt-in to security alerts for different dependency scopes.
> However, this functionality does not yet exist.
### Excluding certain Gradle projects from to the dependency graph
If you do not want the dependency graph to include dependencies from every project in your build,
you can easily exclude certain projects from the dependency extraction process.
To restrict which Gradle subprojects contribute to the report, specify which projects to exclude via a regular expression.
You can provide this value via the `DEPENDENCY_GRAPH_EXCLUDE_PROJECTS` environment variable or system property.
Note that excluding a project in this way only removes dependencies that are _resolved_ as part of that project, and may
not necessarily remove all dependencies _declared_ in that project. If another project depends on the excluded project
then it may transitively resolve dependencies declared in the excluded project: these dependencies will still be included
in the generated dependency graph.
### Excluding certain Gradle configurations from to the dependency graph
Similarly to Gradle projects, it is possible to exclude a set of configuration instances from dependency graph generation,
so that dependencies resolved by those configurations are not included.
To restrict which Gradle configurations contribute to the report, specify which configurations to exclude via a regular expression.
You can provide this value via the `DEPENDENCY_GRAPH_EXCLUDE_CONFIGURATIONS` environment variable or system property.
Note that configuration exclusion applies to the configuration in which the dependency is _resolved_ which is not necessarily
the configuration where the dependency is _declared_. For example if you decare a dependency as `implementation` in
a Java project, that dependency will be resolved in `compileClasspath`, `runtimeClasspath` and possibly other configurations.
### Example of project and configuration filtering
For example, if you want to exclude dependencies in the `buildSrc` project, and exclude dependencies from the `testCompileClasspath` and `testRuntimeClasspath` configurations, you would use the following configuration:
```yaml
jobs:
build:
runs-on:ubuntu-latest
steps:
- name:Checkout sources
uses:actions/checkout@v4
- name:Generate and submit dependency graph
uses:gradle/actions/dependency-submission@v3
env:
# Exclude all dependencies that originate solely in the 'buildSrc' project
DEPENDENCY_GRAPH_EXCLUDE_PROJECTS:':buildSrc'
# Exclude dependencies that are only resolved in test classpaths
The [GitHub Dependency Graph Gradle Plugin](https://plugins.gradle.org/plugin/org.gradle.github-dependency-graph-gradle-plugin)
has other filtering options that may be useful.
See [the docs](https://github.com/gradle/github-dependency-graph-gradle-plugin?tab=readme-ov-file#filtering-which-gradle-configurations-contribute-to-the-dependency-graph) for details.
# Advance usage scenarios
## Using a custom plugin repository
By default, the action downloads the `github-dependency-graph-gradle-plugin` from the Gradle Plugin Portal (https://plugins.gradle.org). If your GitHub Actions environment does not have access to this URL, you can specify a custom plugin repository to use.
Do so by setting the `GRADLE_PLUGIN_REPOSITORY_URL` environment variable.
The GitHub [dependency-review-action](https://github.com/actions/dependency-review-action) helps you
understand dependency changes (and the security impact of these changes) for a pull request,
by comparing the dependency graph for the pull-request with that of the HEAD commit.
Example of a pull request workflow that executes a build for a pull request and runs the `dependency-review-action`:
```yaml
name:Dependency review for pull requests
on:[pull_request ]
permissions:
contents:write
jobs:
dependency-submission:
runs-on:ubuntu-latest
steps:
- name:Checkout sources
uses:actions/checkout@v4
- name:Generate and submit dependency graph
uses:gradle/actions/dependency-submission@v3
dependency-review:
needs:dependency-submission
runs-on:ubuntu-latest
steps:
- name:Perform dependency review
uses:actions/dependency-review-action@v3
```
Note that the `dependency-submission` action submits the dependency graph at the completion of the workflow Job.
For this reason, the `dependency-review-action` must be executed in a dependent job, and not as a subsequent step in the job that generates the dependency graph.
## Usage with pull requests from public forked repositories
This `contents: write` permission is [not available for any workflow that is triggered by a pull request submitted from a public forked repository](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token).
This limitation is designed to prevent a malicious pull request from effecting repository changes.
Because of this restriction, we require 2 separate workflows in order to generate and submit a dependency graph:
1. The first workflow runs directly against the pull request sources and will `generate-and-upload` the dependency graph.
2. The second workflow is triggered on `workflow_run` of the first workflow, and will `download-and-submit` the previously saved dependency graph.
***Main workflow file***
```yaml
name:Generate and save dependency graph
on:[pull_request ]
permissions:
contents:read# 'write' permission is not available
jobs:
dependency-submission:
runs-on:ubuntu-latest
steps:
- name:Checkout sources
uses:actions/checkout@v4
- name:Generate and save dependency graph
uses:gradle/actions/dependency-submission@v3
with:
dependency-graph:generate-and-upload
```
***Dependent workflow file***
```yaml
name:Download and submit dependency graph
on:
workflow_run:
workflows:['Generate and save dependency graph']
types:[completed]
permissions:
contents:write
jobs:
submit-dependency-graph:
runs-on:ubuntu-latest
steps:
- name:Download and submit dependency graph
uses:gradle/actions/dependency-submission@v3
with:
dependency-graph:download-and-submit# Download saved dependency-graph and submit
```
### Integrating `dependency-review-action` for pull requests from public forked repositories
To integrate the `dependency-review-action` into the pull request workflows above, a third workflow file is required.
This workflow will be triggered directly on `pull_request`, but will wait until the dependency graph results are
submitted before the dependency review can complete. The period to wait is controlled by the `retry-on-snapshot-warnings` input parameters.
Here's an example of a separate "Dependency Review" workflow that will wait for 10 minutes for the above PR check workflow to complete.
```yaml
name:dependency-review
on:[pull_request ]
permissions:
contents:read
jobs:
dependency-review:
runs-on:ubuntu-latest
steps:
- name:'Dependency Review'
uses:actions/dependency-review-action@v3
with:
retry-on-snapshot-warnings:true
retry-on-snapshot-warnings-timeout:600
```
The `retry-on-snapshot-warnings-timeout` (in seconds) needs to be long enough to allow the entire `Generate and save dependency graph` and `Download and submit dependency graph` workflows (above) to complete.
# Gradle version compatibility
Dependency-graph generation is compatible with most versions of Gradle >= `5.2`, and is tested regularly against
Gradle versions `5.2.1`, `5.6.4`, `6.0.1`, `6.9.4`, `7.1.1` and `7.6.3`, as well as all patched versions of Gradle 8.x.
A known exception to this is that Gradle `7.0`, `7.0.1` and `7.0.2` are not supported.
See [here](https://github.com/gradle/github-dependency-graph-gradle-plugin?tab=readme-ov-file#gradle-compatibility) for complete compatibility information.
description:Generates a dependency graph for a Gradle project and submits it via the Dependency Submission API
inputs:
gradle-version:
description:|
Gradle version to use. If specified, this Gradle version will be downloaded, added to the PATH and used for invoking Gradle.
If not provided, it is assumed that the project uses the Gradle Wrapper.
required:false
build-root-directory:
description:Path to the root directory of the build. Default is the root of the GitHub workspace.
required:false
cache-encryption-key:
description:|
A base64 encoded AES key used to encrypt the configuration-cache data. The key is exported as 'GRADLE_ENCRYPTION_KEY' for later steps.
A suitable key can be generated with `openssl rand -base64 16`.
Configuration-cache data will not be saved/restored without an encryption key being provided.
required:false
dependency-graph:
description:|
Specifies how the dependency-graph should be handled by this action. By default a dependency-graph will be generated and submitted.
Valid values are:
'generate-and-submit' (default): Generates a dependency graph for the project and submits it in the same Job.
'generate-and-upload': Generates a dependency graph for the project and saves it as a workflow artifact.
'download-and-submit': Retrieves a previously saved dependency-graph and submits it to the repository.
The `generate-and-upload` and `download-and-submit` options are designed to be used in an untrusted workflow scenario,
where the workflow generating the dependency-graph cannot (or should not) be given the `contents: write` permissions
required to submit via the Dependency Submission API.
required:false
default:'generate-and-submit'
additional-arguments:
description:|
Additional arguments to pass to Gradle. For example, `--no-configuration-cache --stacktrace`.
required:false
build-scan-publish:
description:|
Set to 'true' to automatically publish build results as a Build Scan on scans.gradle.com.
For publication to succeed without user input, you must also provide values for `build-scan-terms-of-service-url` and 'build-scan-terms-of-service-agree'.
required:false
default:false
build-scan-terms-of-service-url:
description:The URL to the Build Scan® terms of service. This input must be set to 'https://gradle.com/terms-of-service'.
required:false
build-scan-terms-of-service-agree:
description:Indicate that you agree to the Build Scan® terms of service. This input value must be "yes".
required:false
runs:
using:"composite"
steps:
- name:Check no setup-gradle
shell:bash
run:|
if [ -n "${GRADLE_BUILD_ACTION_SETUP_COMPLETED}" ]; then
echo "The dependency-submission action cannot be used in the same Job as the setup-gradle action. Please use a separate Job for dependency submission."
module.exports=function(e,t){"use strict";varn={};function__webpack_require__(t){if(n[t]){returnn[t].exports}varr=n[t]={i:t,l:false,exports:{}};vari=true;try{e[t].call(r.exports,r,r.exports,__webpack_require__);i=false}finally{if(i)deleten[t]}r.l=true;returnr.exports}__webpack_require__.ab=__dirname+"/";functionstartup(){return__webpack_require__(131)}t(__webpack_require__);returnstartup()}([,function(e,t,n){"use strict";varr=this&&this.__awaiter||function(e,t,n,r){functionadopt(e){returneinstanceofn?e:newn(function(t){t(e)})}returnnew(n||(n=Promise))(function(n,i){functionfulfilled(e){try{step(r.next(e))}catch(e){i(e)}}functionrejected(e){try{step(r["throw"](e))}catch(e){i(e)}}functionstep(e){e.done?n(e.value):adopt(e.value).then(fulfilled,rejected)}step((r=r.apply(e,t||[])).next())})};Object.defineProperty(t,"__esModule",{value:true});consti=n(129);consta=n(622);consto=n(669);consts=n(672);constc=o.promisify(i.exec);functioncp(e,t,n={}){returnr(this,void0,void0,function*(){const{force:r,recursive:i}=readCopyOptions(n);consto=(yields.exists(t))?yields.stat(t):null;if(o&&o.isFile()&&!r){return}constc=o&&o.isDirectory()?a.join(t,a.basename(e)):t;if(!(yields.exists(e))){thrownewError(`no such file or directory: ${e}`)}constu=yields.stat(e);if(u.isDirectory()){if(!i){thrownewError(`Failed to copy. ${e} is a directory, but tried to copy without recursive flag.`)}else{yieldcpDirRecursive(e,c,0,r)}}else{if(a.relative(e,c)===""){thrownewError(`'${c}' and '${e}' are the same file`)}yieldcopyFile(e,c,r)}})}t.cp=cp;functionmv(e,t,n={}){returnr(this,void0,void0,function*(){if(yields.exists(t)){letr=true;if(yields.isDirectory(t)){t=a.join(t,a.basename(e));r=yields.exists(t)}if(r){if(n.force==null||n.force){yieldrmRF(t)}else{thrownewError("Destination already exists")}}}yieldmkdirP(a.dirname(t));yields.rename(e,t)})}t.mv=mv;functionrmRF(e){returnr(this,void0,void0,function*(){if(s.IS_WINDOWS){try{if(yields.isDirectory(e,true)){yieldc(`rd /s /q "${e}"`)}else{yieldc(`del /f /a "${e}"`)}}catch(e){if(e.code!=="ENOENT")throwe}try{yields.unlink(e)}catch(e){if(e.code!=="ENOENT")throwe}}else{lett=false;try{t=yields.isDirectory(e)}catch(e){if(e.code!=="ENOENT")throwe;return}if(t){yieldc(`rm -rf "${e}"`)}else{yields.unlink(e)}}})}t.rmRF=rmRF;functionmkdirP(e){returnr(this,void0,void0,function*(){yields.mkdirP(e)})}t.mkdirP=mkdirP;functionwhich(e,t){returnr(this,void0,void0,function*(){if(!e){thrownewError("parameter 'tool' is required")}if(t){constt=yieldwhich(e,false);if(!t){if(s.IS_WINDOWS){thrownewError(`Unable to locate executable file: ${e}. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also verify the file has a valid extension for an executable file.`)}else{thrownewError(`Unable to locate executable file: ${e}. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.`)}}}try{constt=[];if(s.IS_WINDOWS&&process.env.PATHEXT){for(consteofprocess.env.PATHEXT.split(a.delimiter)){if(e){t.push(e)}}}if(s.isRooted(e)){constn=yields.tryGetExecutablePath(e,t);if(n){returnn}return""}if(e.includes("/")||s.IS_WINDOWS&&e.includes("\\")){return""}constn=[];if(process.env.PATH){for(consteofprocess.env.PATH.split(a.delimiter)){if(e){n.push(e)}}}for(constrofn){constn=yields.tryGetExecutablePath(r+a.sep+e,t);if(n){returnn}}return""}catch(e){thrownewError(`which failed with message ${e.message}`)}})}t.which=which;functionreadCopyOptions(e){constt=e.force==null?true:e.force;constn=Boolean(e.recursive);return{force:t,recursive:n}}functioncpDirRecursive(e,t,n,i){returnr(this,void0,void0,function*(){if(n>=255)return;n++;yieldmkdirP(t);constr=yields.readdir(e);for(constaofr){constr=`${e}/${a}`;consto=`${t}/${a}`;constc=yields.lstat(r);if(c.isDirectory()){yieldcpDirRecursive(r,o,n,i)}else{yieldcopyFile(r,o,i)}}yields.chmod(t,(yields.stat(e)).mode)})}functioncopyFile(e,t,n){returnr(this,void0,void0,function*(){if((yields.lstat(e)).isSymbolicLink()){try{yields.lstat(t);yields.unlink(t)}catch(e){if(e.code==="EPERM"){yields.chmod(t,"0666");yields.unlink(t)}}constn=yields.readlink(e);yields.symlink(n,t,s.IS_WINDOWS?"junction":null)}elseif(!(yields.exists(t))||n){yields.copyFile(e,t)}})}},function(e,t){"use strict";Object.defineProperty(t,"__esModule",{value:true});t.defaultGetter=void0;functiondefaultGetter(e,t){returne[t]}t.defaultGetter=defaultGetter},,,,,,,function(e,t,n){"use strict";varr=this&&this.__awaiter||function(e,t,n,r){functionadopt(e){returneinstanceofn?e:newn(function(t){t(e)})}returnnew(n||(n=Promise))(function(n,i){functionfulfilled(e){try{step(r.next(e))}catch(e){i(e)}}functionrejected(e){try{step(r["throw"](e))}catch(e){i(e)}}functionstep(e){e.done?n(e.value):adopt(e.vaLine truncated
module.exports=function(e,t){"use strict";varn={};function__webpack_require__(t){if(n[t]){returnn[t].exports}vari=n[t]={i:t,l:false,exports:{}};vara=true;try{e[t].call(i.exports,i,i.exports,__webpack_require__);a=false}finally{if(a)deleten[t]}i.l=true;returni.exports}__webpack_require__.ab=__dirname+"/";functionstartup(){return__webpack_require__(878)}returnstartup()}([,function(e,t,n){"use strict";vari=this&&this.__awaiter||function(e,t,n,i){functionadopt(e){returneinstanceofn?e:newn(function(t){t(e)})}returnnew(n||(n=Promise))(function(n,a){functionfulfilled(e){try{step(i.next(e))}catch(e){a(e)}}functionrejected(e){try{step(i["throw"](e))}catch(e){a(e)}}functionstep(e){e.done?n(e.value):adopt(e.value).then(fulfilled,rejected)}step((i=i.apply(e,t||[])).next())})};Object.defineProperty(t,"__esModule",{value:true});consta=n(129);constr=n(622);consto=n(669);consts=n(672);constc=o.promisify(a.exec);functioncp(e,t,n={}){returni(this,void0,void0,function*(){const{force:i,recursive:a}=readCopyOptions(n);consto=(yields.exists(t))?yields.stat(t):null;if(o&&o.isFile()&&!i){return}constc=o&&o.isDirectory()?r.join(t,r.basename(e)):t;if(!(yields.exists(e))){thrownewError(`no such file or directory: ${e}`)}constu=yields.stat(e);if(u.isDirectory()){if(!a){thrownewError(`Failed to copy. ${e} is a directory, but tried to copy without recursive flag.`)}else{yieldcpDirRecursive(e,c,0,i)}}else{if(r.relative(e,c)===""){thrownewError(`'${c}' and '${e}' are the same file`)}yieldcopyFile(e,c,i)}})}t.cp=cp;functionmv(e,t,n={}){returni(this,void0,void0,function*(){if(yields.exists(t)){leti=true;if(yields.isDirectory(t)){t=r.join(t,r.basename(e));i=yields.exists(t)}if(i){if(n.force==null||n.force){yieldrmRF(t)}else{thrownewError("Destination already exists")}}}yieldmkdirP(r.dirname(t));yields.rename(e,t)})}t.mv=mv;functionrmRF(e){returni(this,void0,void0,function*(){if(s.IS_WINDOWS){try{if(yields.isDirectory(e,true)){yieldc(`rd /s /q "${e}"`)}else{yieldc(`del /f /a "${e}"`)}}catch(e){if(e.code!=="ENOENT")throwe}try{yields.unlink(e)}catch(e){if(e.code!=="ENOENT")throwe}}else{lett=false;try{t=yields.isDirectory(e)}catch(e){if(e.code!=="ENOENT")throwe;return}if(t){yieldc(`rm -rf "${e}"`)}else{yields.unlink(e)}}})}t.rmRF=rmRF;functionmkdirP(e){returni(this,void0,void0,function*(){yields.mkdirP(e)})}t.mkdirP=mkdirP;functionwhich(e,t){returni(this,void0,void0,function*(){if(!e){thrownewError("parameter 'tool' is required")}if(t){constt=yieldwhich(e,false);if(!t){if(s.IS_WINDOWS){thrownewError(`Unable to locate executable file: ${e}. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also verify the file has a valid extension for an executable file.`)}else{thrownewError(`Unable to locate executable file: ${e}. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.`)}}}try{constt=[];if(s.IS_WINDOWS&&process.env.PATHEXT){for(consteofprocess.env.PATHEXT.split(r.delimiter)){if(e){t.push(e)}}}if(s.isRooted(e)){constn=yields.tryGetExecutablePath(e,t);if(n){returnn}return""}if(e.includes("/")||s.IS_WINDOWS&&e.includes("\\")){return""}constn=[];if(process.env.PATH){for(consteofprocess.env.PATH.split(r.delimiter)){if(e){n.push(e)}}}for(constiofn){constn=yields.tryGetExecutablePath(i+r.sep+e,t);if(n){returnn}}return""}catch(e){thrownewError(`which failed with message ${e.message}`)}})}t.which=which;functionreadCopyOptions(e){constt=e.force==null?true:e.force;constn=Boolean(e.recursive);return{force:t,recursive:n}}functioncpDirRecursive(e,t,n,a){returni(this,void0,void0,function*(){if(n>=255)return;n++;yieldmkdirP(t);consti=yields.readdir(e);for(constrofi){consti=`${e}/${r}`;consto=`${t}/${r}`;constc=yields.lstat(i);if(c.isDirectory()){yieldcpDirRecursive(i,o,n,a)}else{yieldcopyFile(i,o,a)}}yields.chmod(t,(yields.stat(e)).mode)})}functioncopyFile(e,t,n){returni(this,void0,void0,function*(){if((yields.lstat(e)).isSymbolicLink()){try{yields.lstat(t);yields.unlink(t)}catch(e){if(e.code==="EPERM"){yields.chmod(t,"0666");yields.unlink(t)}}constn=yields.readlink(e);yields.symlink(n,t,s.IS_WINDOWS?"junction":null)}elseif(!(yields.exists(t))||n){yields.copyFile(e,t)}})}},function(e,t){"use strict";Object.defineProperty(t,"__esModule",{value:true});t.defaultGetter=void0;functiondefaultGetter(e,t){returne[t]}t.defaultGetter=defaultGetter},,,,,,,function(e,t,n){"use strict";vari=this&&this.__awaiter||function(e,t,n,i){functionadopt(e){returneinstanceofn?e:newn(function(t){t(e)})}returnnew(n||(n=Promise))(function(n,a){functionfulfilled(e){try{step(i.next(e))}catch(e){a(e)}}functionrejected(e){try{step(i["throw"](e))}catch(e){a(e)}}functionstep(e){e.done?n(e.value):adopt(e.value).then(fulfilled,rejLine truncated
File diff suppressed because it is too large.
Load diff
Loaded 100 of 186 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
daz