Update gradle/gradle-build-action action to v2.12.0

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
gradle/gradle-build-action	action	minor	v2.7.1 -> v2.12.0

---

Release Notes

gradle/gradle-build-action (gradle/gradle-build-action)

v2.12.0

Compare Source

Adds a new option to clear a previously submitted dependency-graph.

steps:
- uses: gradle/gradle-build-action@v2
  with:
    dependency-graph: clear

This may prove useful when migrating to a workflow using the upcoming gradle/actions/dependency-submission action.

Full-changelog: gradle/gradle-build-action@v2.11.1...v2.12.0

v2.11.1

Compare Source

This patch release fixes an issue that prevented the gradle-build-action from executing with Gradle 1.12, and improves error reporting for dependency submission failures.

Changelog

• [FIX] Poor error reporting for dependency-submission failure #​1008
• [FIX] Error with gradle-build-action v2.11.0 and Gradle 1.12: unable to resolve class PluginManager #​1007

Full-changelog: gradle/gradle-build-action@v2.11.0...v2.11.1

v2.11.0

Compare Source

In addition to a number of dependency updates, this release:

• Allows a custom Plugin Repository to be specified when resolving the github-dependency-graph-gradle-plugin. See the documentation for details.
• Brings increased resilience when failures occur collecting build results or cleaning the Gradle User Home. Such failures should no longer prevent the caching of Gradle User Home or lead to build failures.

Changelog

• [NEW] Allow a custom plugin repository to be used to resolve dependency-graph plugin #​933
• [FIX] Cache entries and Job Summary not written on cache-cleanup failure #​990 #​858
• [FIX] Failure to write build results file should not cause overall build to fail #​866

Full-changelog: gradle/gradle-build-action@v2.10.0...v2.11.0

v2.10.0

Compare Source

This release introduces a new artifact-retention-days parameter, which allows a user to configure how long the generated dependency-graph artifacts are retained by GitHub Actions. Adjusting the retention period can be useful to reduce storage costs associated with these dependency-graph artifacts.

See the documentation for more details.

Changelog

• [NEW] Add artifact-retention-days configuration parameter #​903
• [FIX] Update to v1.0.0 of the github-dependency-graph-gradle-plugin
• [FIX] Update @babel/traverse to address reported security vulnerability

Full-changelog: gradle/gradle-build-action@v2.9.0...v2.10.0

v2.9.0

Compare Source

The GitHub dependency-review-action helps you understand dependency changes (and the security impact of these changes) for a pull request. This release updates the GItHub Dependency Graph support to be compatible with the dependency-review-action.

See the documentation for detailed examples.

Changelog

• [FIX] Use correct SHA for pull-request events #​882
• [FIX] Avoid generating dependency graph during cache cleanup #​905
• [NEW] Improve warning on failure to submit dependency graph
• [NEW] Compatibility with GitHub dependency-review-action #​879

Full-changelog: gradle/gradle-build-action@v2.8.1...v2.9.0

v2.8.1

Compare Source

Fixes an issue that prevented Dependency Graph submission when running on GitHub Enterprise Server.

Fixes

• Incorrect endpoint used to submit Dependency Graph on GitHub Enterprise #​885

Changelog

v2.8.0

Compare Source

The v2.8.0 release of the gradle-build-action introduces an easy mechanism to connect to Gradle Enterprise, as well improved support for self-hosted GitHub Actions runners.

Automatic injection of Gradle Enterprise connectivity

It is now possible to connect a Gradle build to Gradle Enterprise without changing any of the Gradle project sources. This is achieved through Gradle Enterprise injection, where an init-script will apply the Gradle Enterprise plugin and associated configuration.

This feature can be useful to easily trial Gradle Enterprise on a project, or to centralize Gradle Enterprise configuration for all GitHub Actions workflows in an organization.

See Gradle Enterprise injection in the README for more info.

Restore Gradle User Home when directory already exists

Previously, the Gradle User Home would not be restored if the directory already exists. This wasn't normally an issue with GitHub-hosted runners, but limited the usefulness of the action for persistent, self-hosted runners.

This behaviour has been improved in this release:

• The Job Summary now includes a useful error message when Gradle User Home was not restored because the directory already exists.
• The action can now be configured to restore the Gradle User Home when the directory already exists, overwriting existing content with content from the GitHub Actions cache. See https://github.com/gradle/gradle-build-action#overwriting-an-existing-gradle-user-home for more details.

Changes

Issues fixed: https://github.com/gradle/gradle-build-action/issues?q=milestone%3A2.8.0+is%3Aclosed
Full changelog: gradle/gradle-build-action@v2.7.1...v2.8.0

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - "before 4am" (UTC).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.