On long-lived machines, it's possible that the `.build-results` directory isn't cleared between invocations. This will result in the job summary including results from previous jobs.
By marking each build-results file as 'processed' at the end of the job, we can avoid this scenario.
While `setup-gradle` must wait until the end of job to submit all of the generated
graphs, the `dependency-submission` action will not save/upload the generated graph
immediately, in the same step where it is generated.
Now, a `dependency-submission` step will trigger a dependency-graph
generation, even if it follows a `setup-gradle` step in the workflow.
Similarly, a `setup-gradle` step with `dependency-graph` configured
will function as expected even if it follows a `setup-gradle` step.
Instead of being a thin wrapper over `setup-gradle`, the `dependency-submission`
action is now a fully-fledged action sharing implementation with `setup-gradle`.
To handle the rebranding of the GE plugin, this PR updates the inject-develocity init script
to apply the `com.gradle.develocity` plugin if `3.17+` version of the plugin is requested.
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'.
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="a8f75513ea"><code>a8f7551</code></a>
Build outputs</li>
<li><a
href="9283312acb"><code>9283312</code></a>
Add new option to clear dependency-graph</li>
<li><a
href="7c8a278ea0"><code>7c8a278</code></a>
Remove old clear-dependency-graph action</li>
<li><a
href="d8ca9b7d2e"><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] <support@github.com>
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.
