The request for a short lived access token fails if the server
certificate is self signed and `develocity-allow-untrusted-server` is
set to true.
I wasn't sure how to write a test for this since nock does not seem to
support mocking a ssl error response.
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.
# Combined PRs ➡️📦⬅️✅ The following pull requests have been successfully combined on this
PR:
- Closes#534 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/kotlin-dsl
- Closes#533 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/java-toolchain
- Closes#532 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/groovy-dsl
- Closes#531 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/.github/workflow-samples/gradle-plugin
- Closes#530 Bump Gradle Wrapper from 8.12 to 8.12.1 in
/sources/test/init-scripts
> This PR was created by the
[`github/combine-prs`](https://github.com/github/combine-prs) action
---------
Signed-off-by: bot-githubaction <bot-githubaction@gradle.com>
Co-authored-by: bot-githubaction <bot-githubaction@gradle.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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
