Remove the Gradle Wrapper validation workflow in favour of setup-gradle - #744
Conversation
…dle` `gradle/actions/setup-gradle` validates the wrapper JAR checksum itself, so the dedicated `gradle/actions/wrapper-validation` action is redundant. Its README states as much: > If you are using setup-gradle in your workflows, it is unlikely that you > will need to use the wrapper-validation action. Every workflow that runs Gradle here already uses `setup-gradle@v6`; the two that do not (`ensure-reports-updated`, `revalidate-versions`) never invoke Gradle at all. Deleting the file from `config` is not enough on its own: `migrate` overlays files with `cp` and never deletes, so consumers that received the workflow earlier would keep running it. `migrate` therefore removes it explicitly, after the `cd ..` so `git` addresses the consumer rather than the `config` submodule, and via `git rm` so the deletion is staged into the pull's own commit. The Hugo-only branch's copy of that removal is now redundant and dropped. Closes #743 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 74e30e2fe9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Pull request overview
This PR retires the standalone “Gradle Wrapper validation” GitHub Actions workflow from the config repository, relying instead on gradle/actions/setup-gradle@v6’s built-in wrapper validation in the workflows that actually run Gradle. It also updates consumer migration behavior and documentation so the retired workflow is removed from repositories that previously received it via migrate.
Changes:
- Deleted
.github/workflows/gradle-wrapper-validation.ymlfromconfig. - Updated
migrateto explicitly remove (and, when tracked, stage deletion of) the workflow in consumer repositories for idempotent cleanup. - Documented the two-step “retire a distributed workflow” process in
README.md(delete inconfig+ explicit removal inmigrate), including a note about branch protection required checks.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| README.md | Documents the two-step retirement process for distributed workflows and notes branch protection implications. |
| migrate | Adds explicit, idempotent removal (tracked via git rm, otherwise rm -f) for the retired workflow in consumer repos. |
| .github/workflows/gradle-wrapper-validation.yml | Removes the redundant wrapper-validation workflow from this repository. |
Closes #743.
Why
gradle/actions/wrapper-validationis redundant whensetup-gradleis already in use. Its README states:Every distributed workflow that actually runs Gradle already uses
gradle/actions/setup-gradle@v6, which validates the wrapper JAR checksumitself:
setup-gradle@v6build-on-ubuntu.ymlbuild-on-windows.ymlincrement-guard.ymlpublish.ymldetekt-code-analysis.ymlensure-reports-updated.ymlrevalidate-versions.ymlSo no repository loses wrapper verification.
What changed
.github/workflows/gradle-wrapper-validation.yml.migratenow removes the workflow from consumers. Deleting it here is notenough on its own:
migrateoverlays files withcpand never deletes, soevery repository that received the workflow earlier would keep running it.
README.mdgained a "Retiring a distributed workflow" section documentingthat two-step requirement, and the neighbouring paragraph was reworded so it
no longer reads as if it covered retirement too.
Two details of the removal block are deliberate:
cd ... For its first ~360 linesmigrateexecuteswith the working directory inside the
configsubmodule, where anygitcommand would address
configrather than the consumer.git rm, notrm. The workflow is a tracked file, so staging thedeletion makes the pull's own commit carry it instead of leaving it dangling
in the working tree. This matches the existing
pom.xml/dependencies.mdcleanup right below it.
The Hugo-only branch had its own
rm -ffor this workflow; that line is nowredundant and was dropped.
Verification
The new block was exercised in throwaway repositories covering all three states,
each run twice to confirm idempotency:
D)bash -n migratepasses. No.kt/.java/.kts/proto/dependency fileschanged, so no Gradle build applies;
confighas no rootversion.gradle.kts,so the version gate is not applicable.
Per the issue, branch protection must be updated in each consumer
repository to drop the now-absent
Validate Gradle Wrapperrequired check.GitHub keeps waiting for a status that no workflow will ever report again, which
blocks every pull request in that repository. This PR cannot do that — it is a
repository setting, not a file.
config's ownmasteris not branch-protected, so this PR is unaffected.🤖 Generated with Claude Code