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.
- 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
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
- 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
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`.
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 `github-dependency-graph-gradle-plugin@v0.0.6`, which reduces
redundancy in the mapping of resolved Gradle dependencies to the GitHub Dependency Graph.
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
The `PluginManager.hasPlugin` method was not detecting the GE plugin when it
was applied during settingsEvaluated.
Switching to `PluginManager.withPlugin` fixes this.
Fixes#626
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
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
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.
