Release automation - #6352
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe release process now validates versions, creates release tags, promotes and signs Phar artifacts, creates draft releases, verifies published assets, updates development repositories, closes milestones, and dispatches website notifications. The checklist documents the automated flow and remaining manual tasks. ChangesRelease automation
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant Maintainer
participant PrepareRelease
participant Bundle as wp-cli/wp-cli-bundle
participant WPCLI as wp-cli/wp-cli
participant ReleaseWorkflow
participant Builds as wp-cli/builds
participant Releases as GitHub Releases
Maintainer->>PrepareRelease: Start stable release
PrepareRelease->>Bundle: Create bundle tag
PrepareRelease->>WPCLI: Create main repository tag
WPCLI->>ReleaseWorkflow: Trigger tagged release
ReleaseWorkflow->>Builds: Promote, checksum, and sign artifacts
ReleaseWorkflow->>Releases: Create draft releases with assets
sequenceDiagram
participant Release as Published release
participant PostReleaseWorkflow
participant WPCLI as wp-cli/wp-cli
participant Bundle as wp-cli/wp-cli-bundle
participant WPDev as wp-cli/wp-cli-dev
participant Website as wp-cli.github.com
Release->>PostReleaseWorkflow: Trigger stable release workflow
PostReleaseWorkflow->>WPCLI: Verify assets and update development version
PostReleaseWorkflow->>Bundle: Reset dependency and alias
PostReleaseWorkflow->>WPDev: Close released milestones
PostReleaseWorkflow->>Website: Dispatch release notification
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/ISSUE_TEMPLATE/4-REGULAR_RELEASE_CHECKLIST.md:
- Around line 94-102: Update
.github/ISSUE_TEMPLATE/4-REGULAR_RELEASE_CHECKLIST.md lines 94-102 to instruct
pushing the matching v2.x.0 tag to wp-cli/wp-cli-bundle before creating its
draft release. Update both gh release create commands in
.github/workflows/release.yml lines 125-130 and 139-144 to include --verify-tag,
ensuring releases fail instead of synthesizing or accepting an incorrect tag.
In @.github/workflows/post-release.yml:
- Around line 75-85: Update the “Reset framework constraint and branch-alias”
workflow step so Composer refreshes composer.lock after changing composer.json,
then stage and commit both files before pushing. Preserve the existing dev-main
requirement and branch-alias update while ensuring the lockfile matches them.
- Around line 25-37: Add a validation step in the workflow before any changes
are pushed to main that reads wp-cli/VERSION and compares it with VERSION
derived from TAG; if they differ, fail the job and skip subsequent milestone or
branch updates. Keep the existing next-version calculations and outputs
unchanged for matching versions.
In @.github/workflows/release.yml:
- Around line 107-116: Update the stable-build commit/push step to detect
whether staged changes exist and skip commit and push when there is no diff. In
the draft release steps, replace create-only commands with `gh release edit` for
existing drafts and `gh release upload --clobber` for assets, preserving
rerun-safe behavior when the tag already exists.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 4d091471-292f-4a64-a612-e44c9482c214
📒 Files selected for processing (3)
.github/ISSUE_TEMPLATE/4-REGULAR_RELEASE_CHECKLIST.md.github/workflows/post-release.yml.github/workflows/release.yml
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/post-release.yml:
- Around line 48-58: Update the version validation step around
CURRENT_BASE_VERSION to also accept the calculated NEXT_ALPHA value as a valid
already-bumped state, allowing retries after the later push while continuing to
reject versions unrelated to RELEASED_VERSION. Preserve the existing mismatch
error and failure behavior for all other values.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: ca03b773-50a0-4233-9372-7a8f0e3b375f
📒 Files selected for processing (3)
.github/ISSUE_TEMPLATE/4-REGULAR_RELEASE_CHECKLIST.md.github/workflows/post-release.yml.github/workflows/release.yml
🚧 Files skipped from review as they are similar to previous changes (2)
- .github/ISSUE_TEMPLATE/4-REGULAR_RELEASE_CHECKLIST.md
- .github/workflows/release.yml
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR introduces GitHub Actions-based automation for WP-CLI’s release and post-release processes, and updates the regular release checklist to align with the new workflow-driven steps.
Changes:
- Added a
Releaseworkflow to generate release notes, promote/sign stable PHAR artifacts, and create/update draft releases forwp-cli/wp-cliandwp-cli/wp-cli-bundle. - Added a
Post-Release Automationworkflow to bump versions/branch-aliases, reset bundle dependencies, close milestones, and dispatch a website notification after a release is published. - Simplified the regular release checklist to reflect the new automated steps and remaining manual tasks.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| .github/workflows/release.yml | New workflow to promote/sign artifacts and create/update draft GitHub releases. |
| .github/workflows/post-release.yml | New workflow to automate post-release version bumps, dependency reset, milestone closure, and website dispatch. |
| .github/ISSUE_TEMPLATE/4-REGULAR_RELEASE_CHECKLIST.md | Updated checklist to match the new automated release flow and remaining manual steps. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Tagging by hand meant pushing two tags in the right order: the wp-cli tag triggers the release workflow, which needs the wp-cli-bundle tag to already exist before it can attach a draft release to it. Nothing enforced that. This workflow tags the bundle first and wp-cli second, and gates both on the checks that were previously spread across the checklist: - the VERSION file on main matches the version being released - wp-cli-bundle has the framework constraint locked to that version - wp-cli-release.phar in the builds repo actually reports that version - neither tag exists yet Tags are pushed with ACTIONS_BOT rather than GITHUB_TOKEN, because pushes made with GITHUB_TOKEN do not trigger further workflow runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xw2XwqE3C4cGGZ6EbS8p3V
Correctness fixes: - post-release ran `wp maintenance close-released`, which is not a registered command. wp-cli-dev's bootstrap registers Release_Command as `maintenance release`, with `close-released` as a subcommand of that, so the milestones were never going to close. - post-release triggered on `release: [published]`, which also fires for pre-releases. Publishing something like v3.0.0-beta.1 would have bumped versions, reset the bundle constraint and closed milestones. It now uses `released`, matching trigger-handbook-regeneration.yml and check-branch-alias.yml, and rejects non-stable versions outright. - The version bump assumed every release is a minor bump and failed the whole run when it was not. A patch release cut from a maintenance branch, or a re-run after the bump already happened, now skips the bump with a notice and still closes milestones and dispatches to the website. - post-release pushed to wp-cli/wp-cli main with GITHUB_TOKEN. main is branch-protected, and pushes made with GITHUB_TOKEN do not trigger downstream workflows such as check-branch-alias. Both repos now use ACTIONS_BOT. Safety: - The stable Phar was promoted, signed and published without ever checking what was in it. wp-cli-release.phar is produced by another workflow in another repository, so nothing tied it to the tag being released; a stale or failed bundle build would have been signed and shipped as stable. The workflow now refuses to continue unless the Phar reports the version being released, and runs the `--info` sanity check the checklist used to ask for by hand. - Signatures and checksums are verified after they are generated, so a mis-imported key or an empty hash file fails the run instead of being published. - Both workflows now name bash explicitly, which enables `-o pipefail`. Without it a failing `sha512sum` in `sha512sum ... | cut ...` produced an empty checksum file that was then signed and published. - Release notes are written to separate files and asserted non-empty before use. `contrib-list` and `release-notes` read from the currently open milestone, so re-running after post-release closes them would otherwise overwrite good release notes with nothing. They are also uploaded as an artifact so they survive a later failure. - Both workflows have a concurrency group, and the builds push retries on top of concurrent nightly pushes rather than failing. - Restores the `deb/php-wpcli_latest_all.deb` symlink update, which the checklist dropped without automating. Adds a verify-release job that post-release depends on. It downloads the published assets and checks the checksums, the GPG signatures, that the Phar runs and reports the right version, that the manifest is valid JSON, and that the release asset is byte-identical to the stable build in wp-cli/builds. None of the version bumps or milestone closures run unless that passes. Both workflows also take a dry_run input that runs everything except the pushes, releases and dispatch, printing what would have changed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xw2XwqE3C4cGGZ6EbS8p3V
Tagging is now done by the Prepare Release workflow rather than by hand, so the manual tag steps are replaced by running that workflow (with a dry run first). Artifact verification is now automated in post-release, so the manual verification step is narrowed to the upgrade path that automation cannot reach. Also corrects the claim that post-release triggers handbook regeneration -- that runs from trigger-handbook-regeneration.yml. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xw2XwqE3C4cGGZ6EbS8p3V
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
.github/ISSUE_TEMPLATE/4-REGULAR_RELEASE_CHECKLIST.md (1)
139-146: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winRemoving the Debian verification step relies on a workflow step that can silently skip.
The automated Debian symlink update in
.github/workflows/release.ymlLines 227-240 emits a::warning::and exits 0 whenphp-wpcli_${VERSION}_all.debis absent. No manual step now catches that case, sophp-wpcli_latest_all.debcan stay pointed at the previous release without anyone noticing.Either restore a short manual verification item here, or make the release workflow fail on a missing
.deb. See the related comment on.github/workflows/release.ymlLines 227-240.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/ISSUE_TEMPLATE/4-REGULAR_RELEASE_CHECKLIST.md around lines 139 - 146, Restore a concise manual checklist item under “Post-Release Manual Tasks” to verify that the Debian symlink points to the newly released php-wpcli_${VERSION}_all.deb, covering the case where the automated release workflow skips the update because the package is missing..github/workflows/post-release.yml (1)
268-289: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winUse the bundle’s own state to gate the bundle reset.
After the first run pushes the
wp-cli/wp-cliversion bump, reruns computeshould_bump=falseand skip thewp-cli/wp-cli-bundlereset. If the first run exited before that step, the bundle remains pinned to the released framework on later reruns. The stagedgit diff --quietcheck already makes this step safe when no bundle changes are needed.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/post-release.yml around lines 268 - 289, Update the condition on the “Reset framework constraint, branch-alias and lockfile in wp-cli/wp-cli-bundle” step to use the bundle repository’s own pending-change state rather than steps.vars.outputs.should_bump. Preserve the existing staged-diff safety check and commit/push behavior so reruns can reset an unfinished bundle without creating unnecessary commits.
🧹 Nitpick comments (5)
.github/workflows/post-release.yml (1)
26-27: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winReduce the workflow token to
contents: read.Every write in this workflow authenticates with
secrets.ACTIONS_BOT: the checkouts at Lines 187-195, 260-266 and 291-295, the milestone step at Line 299, and the dispatch at Line 320. The onlyGITHUB_TOKENuse is the fallback forgh release downloadat Line 80, which needs read access only.
contents: writeon the default token therefore grants more than the workflow uses.🛡️ Proposed change
permissions: - contents: write + contents: read🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/post-release.yml around lines 26 - 27, Change the workflow-level permissions block in post-release.yml from contents: write to contents: read. Keep the existing ACTIONS_BOT-authenticated write operations and the GITHUB_TOKEN fallback for gh release download unchanged.Source: Linters/SAST tools
.github/workflows/release.yml (2)
50-65: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueNon-stable tag pushes will produce a failed workflow run.
This workflow triggers on tag pushes. If someone pushes a pre-release tag such as
v3.0.0-beta.1, the regex rejects it and the job exits 1. That marks a red failure on a legitimate action rather than a skip.Consider filtering the trigger with a tag pattern, or exiting 0 with a
::notice::for non-stable tags and gating later steps on an output. Keepexit 1for theworkflow_dispatchpath, where an invalid input is an operator error.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 50 - 65, Update the Determine version step to distinguish tag-push events from workflow_dispatch using the existing REF_NAME or event context: for non-stable pushed tags, emit a notice and exit successfully while setting an output that prevents later release steps from running; retain exit 1 for invalid workflow_dispatch inputs. Ensure stable tags continue through the existing tag and version outputs.
120-128: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winThe org-wide
composer installis unbounded in both workflows. Thewp-cli-devpre-install-cmdhook clones every repository in the WP-CLI organization. Neither step setstimeout-minutes, so a throttled or stalled clone runs to the default six-hour job limit while holding acancel-in-progress: falseconcurrency group. That blocks all later release runs.
.github/workflows/release.yml#L120-L128: addtimeout-minutesto the "Install dependencies for maintenance tools" step..github/workflows/post-release.yml#L297-L315: addtimeout-minutesto the "Close released milestones across bundle repos" step, and move theDRY_RUNcheck above thecomposer installso a dry run does not pay the clone cost.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 120 - 128, Bound the composer install steps to prevent stalled organization-wide clones from occupying the release concurrency group: in .github/workflows/release.yml lines 120-128, add a suitable timeout-minutes value to the “Install dependencies for maintenance tools” step; in .github/workflows/post-release.yml lines 297-315, add timeout-minutes to the “Close released milestones across bundle repos” step and move its DRY_RUN check before composer install so dry runs skip dependency installation..github/workflows/prepare-release.yml (2)
79-84: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winRead-only checkouts persist the default token. Both workflows check out
wp-cli/buildsfor inspection only, and neither setspersist-credentials: false.actions/checkouttherefore writes theGITHUB_TOKENinto the checked-out.git/config, where any later step or uploaded artifact can read it. zizmor reports this asartipackedat both sites.
.github/workflows/prepare-release.yml#L79-L84: addpersist-credentials: falseto thewp-cli/buildscheckout. Leave thewp-cliandwp-cli-bundlecheckouts at Lines 64-77 unchanged, because their persisted credentials serve the latergit pushsteps..github/workflows/post-release.yml#L150-L159: addpersist-credentials: falseto thewp-cli/buildscheckout, and to thewp-cli-devcheckout at Lines 291-295. Leave thewp-cliandwp-cli-bundlecheckouts unchanged, because they push withsecrets.ACTIONS_BOT.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/prepare-release.yml around lines 79 - 84, Disable credential persistence on the read-only wp-cli/builds checkout in .github/workflows/prepare-release.yml lines 79-84. Also disable it on the wp-cli/builds checkout in .github/workflows/post-release.yml lines 150-159 and the wp-cli-dev checkout in .github/workflows/post-release.yml lines 291-295; leave the wp-cli and wp-cli-bundle checkouts unchanged because their credentials are required for later pushes.Source: Linters/SAST tools
156-186: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winA partial tag push leaves the release in a state that blocks reruns.
The bundle tag is pushed first. If the second push to
wp-cli/wp-clifails, the bundle tag stays in place. A rerun then fails at the "Verify the tags do not already exist" step, because that step treats any existing tag as fatal. Recovery requires manual tag deletion inwp-cli/wp-cli-bundle.Two options:
- Make the existence check tolerant: allow an existing tag when it already points at the expected commit, and fail only on a mismatch.
- Document the manual recovery step in the release checklist so an operator knows to delete the orphaned bundle tag.
Do you want me to draft the tolerant-check version?
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/prepare-release.yml around lines 156 - 186, Update the release tag verification step to allow an existing tag when it already resolves to the expected commit, while failing on missing or mismatched tags. Apply this consistently to both wp-cli-bundle and wp-cli so reruns after a partial push can proceed without manual tag deletion; keep the existing fatal behavior for conflicting tags.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/post-release.yml:
- Around line 116-148: Reorder the workflow so the “Import GPG key” and “Verify
the published GPG signatures” steps run before “Verify the published Phar runs
and reports the right version,” ensuring no Phar command executes before
signature verification. Update the import step to use a GPG_PUBLIC_KEY secret or
another public-key source, remove the private-key and passphrase inputs, and
retain the existing gpg verification commands.
In @.github/workflows/prepare-release.yml:
- Around line 141-154: Update the “Verify the tags do not already exist” step to
capture the exit status of git ls-remote separately from the grep emptiness
check for each repository. Treat any nonzero git ls-remote status as a
validation failure and exit nonzero before release tag creation, while
preserving the existing FOUND=1 behavior when an existing tag is detected.
In @.github/workflows/release.yml:
- Around line 225-240: Update the “Point the latest Debian package” step to fail
when the expected DEB_FILE is missing instead of emitting a warning and exiting
successfully. If package creation is asynchronous, add polling consistent with
the existing bundle-tag polling flow, then terminate with a failure after the
timeout; only create the php-wpcli_latest_all.deb symlink once the package
exists.
---
Outside diff comments:
In @.github/ISSUE_TEMPLATE/4-REGULAR_RELEASE_CHECKLIST.md:
- Around line 139-146: Restore a concise manual checklist item under
“Post-Release Manual Tasks” to verify that the Debian symlink points to the
newly released php-wpcli_${VERSION}_all.deb, covering the case where the
automated release workflow skips the update because the package is missing.
In @.github/workflows/post-release.yml:
- Around line 268-289: Update the condition on the “Reset framework constraint,
branch-alias and lockfile in wp-cli/wp-cli-bundle” step to use the bundle
repository’s own pending-change state rather than
steps.vars.outputs.should_bump. Preserve the existing staged-diff safety check
and commit/push behavior so reruns can reset an unfinished bundle without
creating unnecessary commits.
---
Nitpick comments:
In @.github/workflows/post-release.yml:
- Around line 26-27: Change the workflow-level permissions block in
post-release.yml from contents: write to contents: read. Keep the existing
ACTIONS_BOT-authenticated write operations and the GITHUB_TOKEN fallback for gh
release download unchanged.
In @.github/workflows/prepare-release.yml:
- Around line 79-84: Disable credential persistence on the read-only
wp-cli/builds checkout in .github/workflows/prepare-release.yml lines 79-84.
Also disable it on the wp-cli/builds checkout in
.github/workflows/post-release.yml lines 150-159 and the wp-cli-dev checkout in
.github/workflows/post-release.yml lines 291-295; leave the wp-cli and
wp-cli-bundle checkouts unchanged because their credentials are required for
later pushes.
- Around line 156-186: Update the release tag verification step to allow an
existing tag when it already resolves to the expected commit, while failing on
missing or mismatched tags. Apply this consistently to both wp-cli-bundle and
wp-cli so reruns after a partial push can proceed without manual tag deletion;
keep the existing fatal behavior for conflicting tags.
In @.github/workflows/release.yml:
- Around line 50-65: Update the Determine version step to distinguish tag-push
events from workflow_dispatch using the existing REF_NAME or event context: for
non-stable pushed tags, emit a notice and exit successfully while setting an
output that prevents later release steps from running; retain exit 1 for invalid
workflow_dispatch inputs. Ensure stable tags continue through the existing tag
and version outputs.
- Around line 120-128: Bound the composer install steps to prevent stalled
organization-wide clones from occupying the release concurrency group: in
.github/workflows/release.yml lines 120-128, add a suitable timeout-minutes
value to the “Install dependencies for maintenance tools” step; in
.github/workflows/post-release.yml lines 297-315, add timeout-minutes to the
“Close released milestones across bundle repos” step and move its DRY_RUN check
before composer install so dry runs skip dependency installation.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 672436bb-7f10-4538-a664-4e01d6ebb0d2
📒 Files selected for processing (4)
.github/ISSUE_TEMPLATE/4-REGULAR_RELEASE_CHECKLIST.md.github/workflows/post-release.yml.github/workflows/prepare-release.yml.github/workflows/release.yml
| - name: Verify the published Phar runs and reports the right version | ||
| env: | ||
| VERSION: ${{ steps.vars.outputs.version }} | ||
| run: | | ||
| cd verify | ||
|
|
||
| PHAR_VERSION="$(php "wp-cli-${VERSION}.phar" --version | awk '{print $2}')" | ||
|
|
||
| if [ "$PHAR_VERSION" != "$VERSION" ]; then | ||
| echo "::error::Published Phar reports '$PHAR_VERSION' but the release is '$VERSION'." | ||
| exit 1 | ||
| fi | ||
|
|
||
| php "wp-cli-${VERSION}.phar" --info | ||
|
|
||
| if ! jq -e . "wp-cli-${VERSION}.manifest.json" > /dev/null; then | ||
| echo "::error::wp-cli-${VERSION}.manifest.json is not valid JSON." | ||
| exit 1 | ||
| fi | ||
|
|
||
| - name: Import GPG key | ||
| uses: crazy-max/ghaction-import-gpg@cb9bde2e2525e6865904e392450c3401a753db76 # v6.2.0 | ||
| with: | ||
| gpg_private_key: ${{ secrets.GPG_PRIVATE_KEY }} | ||
| passphrase: ${{ secrets.GPG_PASSPHRASE }} | ||
|
|
||
| - name: Verify the published GPG signatures | ||
| env: | ||
| VERSION: ${{ steps.vars.outputs.version }} | ||
| run: | | ||
| cd verify | ||
| gpg --verify "wp-cli-${VERSION}.phar.asc" "wp-cli-${VERSION}.phar" | ||
| gpg --verify "wp-cli-${VERSION}.phar.gpg" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Verify the GPG signature before you execute the downloaded Phar, and import only the public key.
Two ordering and scope problems:
-
Lines 122 and 129 run the downloaded artifact with
php. The signature check that establishes its authenticity does not run until Lines 142-148. The workflow therefore executes the artifact before it trusts it. Move the "Import GPG key" and "Verify the published GPG signatures" steps ahead of "Verify the published Phar runs and reports the right version". -
crazy-max/ghaction-import-gpgimports the private signing key with its passphrase. Verification needs only the public key. This job never signs anything, so the private key andGPG_PASSPHRASEare exposed to a runner for no functional reason. Import the public key instead.
The combination matters: the runner executes an unverified binary and then holds the release signing key and ACTIONS_BOT.
🛡️ Proposed restructuring
+ - name: Import the release public key
+ env:
+ GPG_PUBLIC_KEY: ${{ secrets.GPG_PUBLIC_KEY }}
+ run: |
+ printf '%s' "$GPG_PUBLIC_KEY" | gpg --batch --import
+
+ - name: Verify the published GPG signatures
+ env:
+ VERSION: ${{ steps.vars.outputs.version }}
+ run: |
+ cd verify
+ gpg --verify "wp-cli-${VERSION}.phar.asc" "wp-cli-${VERSION}.phar"
+ gpg --verify "wp-cli-${VERSION}.phar.gpg"
+
- name: Verify the published Phar runs and reports the right version
env:
VERSION: ${{ steps.vars.outputs.version }}
run: |
cd verify
PHAR_VERSION="$(php "wp-cli-${VERSION}.phar" --version | awk '{print $2}')"
if [ "$PHAR_VERSION" != "$VERSION" ]; then
echo "::error::Published Phar reports '$PHAR_VERSION' but the release is '$VERSION'."
exit 1
fi
php "wp-cli-${VERSION}.phar" --info
if ! jq -e . "wp-cli-${VERSION}.manifest.json" > /dev/null; then
echo "::error::wp-cli-${VERSION}.manifest.json is not valid JSON."
exit 1
fi
-
- - name: Import GPG key
- uses: crazy-max/ghaction-import-gpg@cb9bde2e2525e6865904e392450c3401a753db76 # v6.2.0
- with:
- gpg_private_key: ${{ secrets.GPG_PRIVATE_KEY }}
- passphrase: ${{ secrets.GPG_PASSPHRASE }}
-
- - name: Verify the published GPG signatures
- env:
- VERSION: ${{ steps.vars.outputs.version }}
- run: |
- cd verify
- gpg --verify "wp-cli-${VERSION}.phar.asc" "wp-cli-${VERSION}.phar"
- gpg --verify "wp-cli-${VERSION}.phar.gpg"This needs a new GPG_PUBLIC_KEY secret, or a fetch of the published key from a keyserver.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/post-release.yml around lines 116 - 148, Reorder the
workflow so the “Import GPG key” and “Verify the published GPG signatures” steps
run before “Verify the published Phar runs and reports the right version,”
ensuring no Phar command executes before signature verification. Update the
import step to use a GPG_PUBLIC_KEY secret or another public-key source, remove
the private-key and passphrase inputs, and retain the existing gpg verification
commands.
| - name: Verify the tags do not already exist | ||
| env: | ||
| TAG: ${{ steps.vars.outputs.tag }} | ||
| run: | | ||
| FOUND=0 | ||
|
|
||
| for REPO in wp-cli/wp-cli wp-cli/wp-cli-bundle; do | ||
| if git ls-remote --tags "https://github.com/${REPO}.git" "refs/tags/${TAG}" | grep -q .; then | ||
| echo "::error::Tag $TAG already exists in $REPO." | ||
| FOUND=1 | ||
| fi | ||
| done | ||
|
|
||
| exit "$FOUND" |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
The tag-existence check fails open on git ls-remote errors.
git ls-remote runs inside an if condition, so set -e and pipefail do not stop the step. If the remote call fails for a transient network or auth reason, grep -q . sees no input, the check reports "tag does not exist", and the workflow proceeds to create and push both tags. Tag pushes are effectively irreversible for a release, so this validation must fail closed.
Capture the git ls-remote exit status separately from the emptiness test.
🛡️ Proposed fix
run: |
FOUND=0
for REPO in wp-cli/wp-cli wp-cli/wp-cli-bundle; do
- if git ls-remote --tags "https://github.com/${REPO}.git" "refs/tags/${TAG}" | grep -q .; then
+ if ! REFS="$(git ls-remote --tags "https://github.com/${REPO}.git" "refs/tags/${TAG}")"; then
+ echo "::error::Could not query tags in $REPO. Refusing to continue."
+ exit 1
+ fi
+
+ if [ -n "$REFS" ]; then
echo "::error::Tag $TAG already exists in $REPO."
FOUND=1
fi
done
exit "$FOUND"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Verify the tags do not already exist | |
| env: | |
| TAG: ${{ steps.vars.outputs.tag }} | |
| run: | | |
| FOUND=0 | |
| for REPO in wp-cli/wp-cli wp-cli/wp-cli-bundle; do | |
| if git ls-remote --tags "https://github.com/${REPO}.git" "refs/tags/${TAG}" | grep -q .; then | |
| echo "::error::Tag $TAG already exists in $REPO." | |
| FOUND=1 | |
| fi | |
| done | |
| exit "$FOUND" | |
| - name: Verify the tags do not already exist | |
| env: | |
| TAG: ${{ steps.vars.outputs.tag }} | |
| run: | | |
| FOUND=0 | |
| for REPO in wp-cli/wp-cli wp-cli/wp-cli-bundle; do | |
| if ! REFS="$(git ls-remote --tags "https://github.com/${REPO}.git" "refs/tags/${TAG}")"; then | |
| echo "::error::Could not query tags in $REPO. Refusing to continue." | |
| exit 1 | |
| fi | |
| if [ -n "$REFS" ]; then | |
| echo "::error::Tag $TAG already exists in $REPO." | |
| FOUND=1 | |
| fi | |
| done | |
| exit "$FOUND" |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/prepare-release.yml around lines 141 - 154, Update the
“Verify the tags do not already exist” step to capture the exit status of git
ls-remote separately from the grep emptiness check for each repository. Treat
any nonzero git ls-remote status as a validation failure and exit nonzero before
release tag creation, while preserving the existing FOUND=1 behavior when an
existing tag is detected.
| # Previously a manual checklist item that this automation dropped: apt | ||
| # users resolve php-wpcli_latest_all.deb, so it has to follow stable. | ||
| - name: Point the latest Debian package at the new stable version | ||
| env: | ||
| VERSION: ${{ steps.vars.outputs.version }} | ||
| run: | | ||
| cd builds/deb | ||
| DEB_FILE="php-wpcli_${VERSION}_all.deb" | ||
|
|
||
| if [ ! -f "$DEB_FILE" ]; then | ||
| echo "::warning::$DEB_FILE not found in wp-cli/builds; leaving php-wpcli_latest_all.deb untouched." | ||
| exit 0 | ||
| fi | ||
|
|
||
| ln -sfn "$DEB_FILE" php-wpcli_latest_all.deb | ||
| echo "php-wpcli_latest_all.deb -> $DEB_FILE" |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
A missing Debian package silently leaves php-wpcli_latest_all.deb on the previous release.
When php-wpcli_${VERSION}_all.deb is absent, this step emits a ::warning:: and exits 0. The release then completes as a success while apt users keep resolving the previous version through php-wpcli_latest_all.deb.
The previous manual Debian verification item was removed from .github/ISSUE_TEMPLATE/4-REGULAR_RELEASE_CHECKLIST.md Lines 139-146, so nothing else catches this. A warning annotation in a green run is easy to miss.
Fail the step instead. If the .deb is genuinely produced asynchronously by another workflow, poll for it the way the bundle tag is polled at Lines 277-295, then fail on timeout.
🐛 Proposed fix
if [ ! -f "$DEB_FILE" ]; then
- echo "::warning::$DEB_FILE not found in wp-cli/builds; leaving php-wpcli_latest_all.deb untouched."
- exit 0
+ echo "::error::$DEB_FILE not found in wp-cli/builds. php-wpcli_latest_all.deb would keep pointing at the previous release."
+ exit 1
fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Previously a manual checklist item that this automation dropped: apt | |
| # users resolve php-wpcli_latest_all.deb, so it has to follow stable. | |
| - name: Point the latest Debian package at the new stable version | |
| env: | |
| VERSION: ${{ steps.vars.outputs.version }} | |
| run: | | |
| cd builds/deb | |
| DEB_FILE="php-wpcli_${VERSION}_all.deb" | |
| if [ ! -f "$DEB_FILE" ]; then | |
| echo "::warning::$DEB_FILE not found in wp-cli/builds; leaving php-wpcli_latest_all.deb untouched." | |
| exit 0 | |
| fi | |
| ln -sfn "$DEB_FILE" php-wpcli_latest_all.deb | |
| echo "php-wpcli_latest_all.deb -> $DEB_FILE" | |
| # Previously a manual checklist item that this automation dropped: apt | |
| # users resolve php-wpcli_latest_all.deb, so it has to follow stable. | |
| - name: Point the latest Debian package at the new stable version | |
| env: | |
| VERSION: ${{ steps.vars.outputs.version }} | |
| run: | | |
| cd builds/deb | |
| DEB_FILE="php-wpcli_${VERSION}_all.deb" | |
| if [ ! -f "$DEB_FILE" ]; then | |
| echo "::error::$DEB_FILE not found in wp-cli/builds. php-wpcli_latest_all.deb would keep pointing at the previous release." | |
| exit 1 | |
| fi | |
| ln -sfn "$DEB_FILE" php-wpcli_latest_all.deb | |
| echo "php-wpcli_latest_all.deb -> $DEB_FILE" |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release.yml around lines 225 - 240, Update the “Point the
latest Debian package” step to fail when the expected DEB_FILE is missing
instead of emitting a warning and exiting successfully. If package creation is
asynchronous, add polling consistent with the existing bundle-tag polling flow,
then terminate with a failure after the timeout; only create the
php-wpcli_latest_all.deb symlink once the package exists.
Nothing consumes it. wp-cli/wp-cli.github.com has no repository_dispatch workflow and no reference to the release-published event type, and createDispatchEvent returns 204 regardless of whether anything is listening, so the step went green either way. The site it targets is no longer maintained, so there is nothing to trigger. Removed the step, the now-unused TAG job variable, and the corresponding line in the release checklist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xw2XwqE3C4cGGZ6EbS8p3V
The site these steps target is no longer maintained, so verifying its readme, updating homepage version references and tagging a website release are all dead work. The regular release checklist lost the same section earlier in this branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xw2XwqE3C4cGGZ6EbS8p3V
Needs rigorous testing. Requires some new secrets too.
Required secrets & permissions
These have to be in place before this can run against a real release.
Secrets
GPG_PRIVATE_KEYrelease.yml,post-release.ymlreleases@wp-cli.org. Newly required inpost-release.yml, which verifies the published signatures before anything is bumped or closed.GPG_PASSPHRASErelease.yml,post-release.ymlACTIONS_BOTACTIONS_BOTscope onwp-cli/wp-cliPreviously this token was only used against other repositories (
wp-cli/builds,wp-cli/wp-cli-bundle). It is now also used againstwp-cli/wp-cliitself, and needs to be able to:prepare-release.ymlcreates the release tags.GITHUB_TOKENcannot be used here: pushes made with it do not trigger further workflow runs, sorelease.ymlwould never start.release.ymlpreviously usedGITHUB_TOKENfor thewp-clidraft release andACTIONS_BOTfor the bundle one; both now useACTIONS_BOT.main—post-release.ymlcommits the version bump.mainis branch-protected, so the bot has to be a bypass actor on that branch, otherwise the post-release bump fails. This was already true of the originalGITHUB_TOKENversion of that step, which would not have worked either.Worth considering as a follow-up: replacing the long-lived
ACTIONS_BOTPAT withactions/create-github-app-token, so each run gets a short-lived, per-repository token instead of one credential with write access across several repositories.Summary by CodeRabbit
New Features
Documentation