This pull request primarily updates dependencies to ensure compatibility
and benefit from the latest features and fixes. The most significant
changes include upgrading the Develocity Gradle plugin and related
workflow/test matrix versions, as well as updating several
JavaScript/TypeScript development dependencies.
**Gradle and Develocity plugin updates:**
* Updated the `com.gradle.develocity` plugin version from `4.3.2` to
`4.4.0` across all workflow sample Gradle files and documentation. This
ensures the latest features and fixes are used in all example and test
projects.
[[1]](diffhunk://#diff-76298366dd6b8dd6f26592596c333884930a893c9553247c720b151c4e2ca314L2-R2)
[[2]](diffhunk://#diff-d4c2e31d274e47ae44389c511a1ba7fb24275335d155de5d013bcfa1631da3f4L2-R2)
[[3]](diffhunk://#diff-8ccb433ca9eee93c137fed07a97f755e10aae3a5989fbcd9eae427383a8c2243L2-R2)
[[4]](diffhunk://#diff-f71438b1f838b2006cbff9be742ce918a0a53dfa51ab838f480517f63da54e55L2-R2)
[[5]](diffhunk://#diff-f7ae8d202a355a0d67ecbaf0d3b18c5bc0ef3d94a546724ff776b20517d4318cL867-R867)
* Changed the Develocity plugin version in the integration test matrix
and related access key logic from `4.3.2` to `4.4.0` in the GitHub
Actions workflow configuration.
[[1]](diffhunk://#diff-670fc94ebca0a47e5491678ac19b6eeb5c06bbe5fb1786748f38b3a983564543L33-R33)
[[2]](diffhunk://#diff-670fc94ebca0a47e5491678ac19b6eeb5c06bbe5fb1786748f38b3a983564543L46-R46)
[[3]](diffhunk://#diff-670fc94ebca0a47e5491678ac19b6eeb5c06bbe5fb1786748f38b3a983564543L95-R95)
[[4]](diffhunk://#diff-670fc94ebca0a47e5491678ac19b6eeb5c06bbe5fb1786748f38b3a983564543L151-R151)
[[5]](diffhunk://#diff-670fc94ebca0a47e5491678ac19b6eeb5c06bbe5fb1786748f38b3a983564543L194-R194)
**GitHub Actions workflow updates:**
* Upgraded the `gradle/actions/setup-gradle` and
`gradle/actions/wrapper-validation` actions from v5.0.2 to v6.0.1 in all
relevant workflows, ensuring compatibility with the latest Gradle and
GitHub Actions features.
[[1]](diffhunk://#diff-67e3ccddaa5be01f56241af95a472ecc7b4eea0f6c71adb38e109207ea643af2L29-R29)
[[2]](diffhunk://#diff-20def8dd090267382644676ff63075fd8c64a9c8a9eeae936fc2451b10c063ccL33-R33)
[[3]](diffhunk://#diff-97df74640aaaa8bf2c853ceb34bc83eda56f6a670a91ef5a27e5c9ffcf1c9378L15-R15)
* Updated the `github/codeql-action/init` and
`github/codeql-action/analyze` actions to a new commit SHA, maintaining
up-to-date security scanning.
**JavaScript/TypeScript dependency updates:**
* Upgraded `@typescript-eslint/eslint-plugin` from `8.57.1` to `8.57.2`,
`eslint` from `10.0.3` to `10.1.0`, and `typescript` from `5.9.3` to
`6.0.2` in `sources/package-lock.json`, along with related dependency
tree updates for improved linting and TypeScript support.
[[1]](diffhunk://#diff-7e4a393257b8b2f1b2d998903badbc3175139afc4f7959f1a80f3a2fac68ecebL34-R44)
[[2]](diffhunk://#diff-7e4a393257b8b2f1b2d998903badbc3175139afc4f7959f1a80f3a2fac68ecebL1679-R1685)
[[3]](diffhunk://#diff-7e4a393257b8b2f1b2d998903badbc3175139afc4f7959f1a80f3a2fac68ecebL2857-R2867)
[[4]](diffhunk://#diff-7e4a393257b8b2f1b2d998903badbc3175139afc4f7959f1a80f3a2fac68ecebL2880-R2925)
[[5]](diffhunk://#diff-7e4a393257b8b2f1b2d998903badbc3175139afc4f7959f1a80f3a2fac68ecebL2917-R2946)
[[6]](diffhunk://#diff-7e4a393257b8b2f1b2d998903badbc3175139afc4f7959f1a80f3a2fac68ecebL2943-R2988)
[[7]](diffhunk://#diff-7e4a393257b8b2f1b2d998903badbc3175139afc4f7959f1a80f3a2fac68ecebR2997-R3015)
This is necessary to avoid loading a cache entry from a different test,
where the allowed wrapper checksums might have been cached, causing the
wrapper validation to unexpectedly succeed.
With licensing changes in v6, a license warning was added to the logs
and job summary. Now, accepting the Build Scan Terms of Use or providing
a Develocity Access Key will mute this warning.
Introduces type descriptor YAML files for GitHub
Actions in the repository, improving type safety and documentation for
action inputs and outputs. It also adds a new GitHub Actions workflow to
validate these typings automatically on pushes and pull requests. The
changes are grouped into the addition of type descriptor files for
various actions and the automation of their validation.
https://github.com/typesafegithub/github-actions-typing
**Type descriptor files for GitHub Actions:**
* Added `action-types.yml` files to `setup-gradle`,
`dependency-submission`, and `wrapper-validation` actions, specifying
input and output types for each action to improve type safety and
documentation.
[[1]](diffhunk://#diff-542de74831b6dc1954ff20a4c329b170053c82087ea7df742bd536156133f25bR1-R171)
[[2]](diffhunk://#diff-44708a3af3d0f3cfed1873f9b77d7e815c6c14e941fa3dd5ed08835a69d67855R1-R146)
[[3]](diffhunk://#diff-3fe1028d7aa5ee815c90fa580d4f62e646f0b9a4b7372f227fc131a56948ace0R1-R17)
**Automation and validation:**
* Introduced a new GitHub Actions workflow
`.github/workflows/ci-validate-typings.yml` to automatically validate
action typings on pushes to `main` and `release/**` branches, as well as
on pull requests. This uses the `github-actions-typing` action for
validation.
With this change, the caching functionality of `setup-gradle` and
`dependency-submission` is now provided by `gradle-actions-caching`, a
closed-source library distributed under our [Terms of
Use](https://gradle.com/legal/terms-of-use/). The rest of the action
implementation remains open source.
Using `setup-gradle` or `dependency-submission` with caching enabled
involves loading and using the `gradle-actions-caching` component,
requiring acceptance of the [Terms of
Use](https://gradle.com/legal/terms-of-use/). There are no functional
changes to caching provided by these actions: all workflows will
continue to function as before.
The non-caching aspects of action implementation remain open source. By
running these actions with caching disabled they can be used without
ever loading `gradle-actions-caching` or accepting the license terms.
Supporting the caching infrastructure in this project requires a
substantial engineering investment by Gradle Technologies, which we can
sustain thanks to Develocity, our commercial offering. Caching
technologies are a core part of the Develocity offering, and the caching
in `setup-gradle` fits squarely in that space.
This licensing change lets us continue to build advanced capabilities
that go beyond what we would offer as open source. Proper
production-ready Configuration Cache support will be the first
capability. Improving build performance for self-hosted runners will
follow.
We may introduce functionality restrictions in future updates. However,
caching functionality will remain free for public repositories.
We have a long-standing commitment to open source, as maintainers of
Gradle Build Tool, and by [sponsoring the open source
community](https://gradle.com/oss-sponsored-by-develocity/) with free
Develocity licenses. Public repositories are primarily used by open
source projects, and we remain committed to supporting them.
- Implementation of caching logic to save and restore Gradle User Home
content has been removed, replaced by the `gradle-actions-caching`
component.
- The `@actions/caching` library is still used to cache Gradle
distributions that are downloaded and provisioned by `setup-gradle`.
This PR updates to the latest version of `@actions/caching`, and removes
the patch that is no longer required.
- License notices are now displayed in documentation, logs and the
generated Job Summary.
Removes support for configuration-cache extraction and restore from the
caching workflow and related source code. Configuration-cache support
only worked for a limited set of projects (gradle/actions#21), and we
plan to reimplement this properly as part of the
`gradle-actions-caching` project.
The main impact is simplification of the caching logic, focusing only on
common Gradle artifacts. The `ConfigurationCacheEntryExtractor` class
and related logic were deleted from
`sources/src/caching/gradle-home-extry-extractor.ts`.
By inspecting a greater range of build operations for failure, the Job
summary will correctly reflect the build outcome in more circumstances.
Note that we now use the old 'buildFinished' mechanism for all Gradle
versions < `7.0`, instead of using the BuildService mechanism for all
Gradle versions from `6.6`. This avoids needing to deal with
inconsistent build operations present in Gradle versions `[6.6, 7.0)`.
Fixes#415
Automatically generated pull request to update the known wrapper
checksums.
In case of conflicts, manually run the workflow from the [Actions
tab](https://github.com/gradle/actions/actions/workflows/update-checksums-file.yml),
the changes will then be force-pushed onto this pull request branch.
Do not manually update the pull request branch; those changes might get
overwritten.
> [!IMPORTANT]
> GitHub workflows have not been executed for this pull request yet.
Before merging, close and then directly reopen this pull request to
trigger the workflows.
Fixes the Groovy syntax in 2 init-scripts to avoid deprecation warnings.
The fix to the DV injection script is temporary, and will be replaced by
a fix in the upstream reference script.
Fixes#541
Due to an issue with dependency-review-action (https://github.com/gradle/actions/issues/482),
the setup described in the documentation can result in duplicate
dependencies being added to the dependency graph.
To avoid this, we now recommend using a common `dependency-submission`
workflow for both pushes to `main` and pull requests.
The `dependency-review` workflow runs on any `pull_request` but will wait
for the `dependency-submission` to complete.
This setup works for both the standard setup, and for the advanced setup for
pull requests from repository forks.
The cache-cleanup operation works by executing Gradle on a dummy project
and a custom init-script. The version of Gradle used should be at least
as high as the newest version used to run a build.
Previously, if the Gradle version on PATH didn't meet this requirement,
the action would download and install the required Gradle version.
With this PR, the action will now use an existing Gradle wrapper
distribution if it meets the requirement. This avoids unnecessary
downloads of Gradle versions that are already present on the runner.
The logic is:
- Determine the newest version of Gradle that was executed during the
Job. This is the 'minimum version' for cache cleanup.
- Inspect the Gradle version on PATH and any detected wrapper scripts to
see if they meet the 'minimum version'.
- The first executable that is found to meet the requirements will be
used for cache-cleanup.
- If no executable is found that meets the requirements, attempt to
provision Gradle with the 'minimum version'.
Fixes#515
The cache-cleanup operation works by executing Gradle on a dummy project
and a custom init-script. The init-script requires at least Gradle 8.11
to work.
Ideally, the version of Gradle used for cleanup should be no older than
the newest one that wrote entries to Gradle User Home. If an older
Gradle version is used for cache-cleanup, it will not remove entries
written specifically for newer versions.
With this change, we now attempt to ensure that cache-cleanup is run
with the best Gradle version available. We inspect the Gradle version on
PATH to see if it is new enough, otherwise we will provision a Gradle
version equal to the newest one that ran in the Job.
The logic is:
- Determine the newest version of Gradle that was executed during the
Job. This is the 'minimum version' for cache cleanup.
- Inspect the Gradle version on PATH (if any) to see if it is equal to
or newer than the 'minimum version'.
- If the version Gradle on PATH is new enough, use that version for
cache-cleanup.
- If not, attempt to provision Gradle with the 'minimum version'.
Fixes#436
This change primarily impacts test projects and documentation. The only
material impact is that CCUD 2.1 will now be auto-applied when
publishing Build Scans automatically with `build-scan-publish: true`.
(Develocity injection does not hard-code any CCUD version)
Diagnosing unexpected dependencies in the GitHub Dependency Graph can
be difficult. In order to aid with diagnosis, the `dependency-submission`
action will now save each dependency-graph file as a workflow artifact.
If this is undesirable, the prior behaviour can be restored by explicitly setting
`dependency-graph: generate-and-submit`.
Fixes#519
The Gradle build used to perform cache-cleanup will run in the context of init-scripts
provided by the action, including those that collect build-results.
In some circumstances this can lead to unexpected results, such as saving configuration-cache
entries for cache cleanup executions.
With this change, build results will not be captured for cache-cleanup builds.
Previously we were relying on Gradle to substitute JDK environment variables
in toolchains.xml. With this change, the actual path to the JDK is encoded instead.
This should avoid issues where Gradle is not able to successfully resolve the
envioronment variable.
