Repository navigation
Document the release process in RELEASING.md - #546
Merged
Merged
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository: WordPress/contributor-toolkit/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
ryanwelcher
added a commit
that referenced
this pull request
Oct 8, 2026
…wn (#660) ## Why Every pull request runs the unit suite and the E2E journeys and packaged smoke on macOS and Windows, and all six checks are required to merge. A pull request that only changes Markdown (README, RELEASING.md, AGENTS.md and the like) waits on all of them even though nothing they test has changed. ## What changes A pull request whose changed files all end in `.md` skips the unit suite, the journeys and the packaged smoke, and still merges. `paths-ignore` cannot do this. A workflow it skips never reports its checks, so the required ones would sit at "pending" and block the merge. Instead, each workflow gets a small `changes` job on Linux that reads the PR's file list from the API. When only Markdown changed, `*-skipped` stub jobs report the same required check names as passed, and the real jobs are skipped. Pushes to trunk always run everything. Deliberately not in it: anything under `docs/` that is not Markdown (`tests/unit/download-button-platform.test.cjs` reads `docs/.vitepress/theme`), screenshots, and Lint, which is quick and also required. ## How to test this Platforms: none, this is CI only. The checks on this PR and the next Markdown-only PR are the test. **Starting state:** this PR, which changes two workflow files. 1. Look at the checks on this PR. Expected: `changes` reports `code=true`, and the real `unit`, `Journeys` and `Packaged smoke` jobs run on macOS and Windows. 2. On a Markdown-only PR opened after this merges (or a throwaway one against this branch), look at the checks. Expected: the six required checks show as passed within about a minute, each from a job that prints "Only Markdown changed", and no macOS or Windows runner starts. 3. Edit that PR's title. Expected: a new run appears with every job skipped, and the six required checks keep their earlier passes. **What must not have happened:** - A PR with any non-Markdown file skipping a suite. The file test was checked by hand for Markdown only, Markdown plus `.js`, a VitePress config change, an empty list and a `.js` file renamed to `.md`, and against the real file lists of #546 (Markdown only, skips) and #654 (code, runs). - A required check left at "pending" on a Markdown-only PR. - A title edit cancelling a suite that is still running. **Cannot be tested here:** the base-move case below needs a stacked pair of PRs to retarget, which I did not stage. ## Risks and limitations - If the `changes` job fails (for example the API call errors), both the real and the stub jobs skip, so the required checks stay pending. That blocks the merge rather than letting it through, and re-running the workflow clears it. - Moving a PR's base re-runs `changes`. Without that, a Markdown-only PR stacked on a code PR and moved onto trunk by hand would keep its stub passes while its diff now contains the lower PR's code. The workflows now listen for `edited` and act only when the base changed. One unverified detail: whether the PR's file list already reflects the new base when the `edited` run starts. - The `changes` script is copied into both workflows rather than shared. Sharing it would mean a composite action for twenty lines. - Pre-PR review: 1 finding, fixed (see below). ## Related None. --- <details> <summary>Design decisions and alternatives considered</summary> - **`paths-ignore` / `paths`:** rejected, the required checks would never report. - **A job-level `if:` on the existing matrix jobs alone:** rejected. A skipped matrix job is not expanded, so it reports one check named literally `Journeys (${{ matrix.os }})`, and the required `Journeys (macos-latest)` never appears. This is already what happens to drafts today (see #283's checks). - **A step-level `if:` on every step of the real jobs, with `runs-on` falling back to Linux:** works, but every new step would need the guard, and a missed one would run `npm ci` on the wrong runner. The stub jobs keep the real jobs unchanged apart from `needs` and `if`. - **Changing the ruleset to require one gate job per workflow:** needs an admin change to the ruleset and moves the required names; the stubs need neither. - **`dorny/paths-filter`:** a third-party action holding a token, for something `gh api` does in one call. </details> <details> <summary>Review outcome</summary> 1 [fix here] after promotion · 0 left open. Lint clean; unit suite 2081 pass, 0 fail, 2 skipped (local, macOS). - **Review:** completed, separate agent context, head `ee41b6d` / base `6d5f334`. One 🟡 finding, raised as follow-up and fixed here at the author's request: a Markdown-only stacked PR moved onto trunk by hand kept its stub passes, since neither workflow listened for `edited`. Also noted, left as is: the `changes` script is duplicated across the two workflows. - **Since review:** `ee41b6d → 251885f` re-reviewed by a separate agent context: finding resolved, no new findings. Checked title-only edits (earlier passes stand), base-move cancellation, the concurrency group expression for every event, and drafts. - **CodeRabbit:** not requested yet. </details> <details> <summary>Implementation notes</summary> - The file list comes from `gh api --paginate repos/…/pulls/N/files` (up to 3000 files), taking `previous_filename` too, so a `.js` renamed to `.md` counts as code. - The test is `grep -v '\.md$' > /dev/null`, not `grep -qv`. Not every `grep` handles `-q` with `-v` the same way. - An empty file list counts as code. - The `changes` job swaps `contents: read` for `pull-requests: read`; it never checks out. Fork PRs get that permission too. - The concurrency group gets an `-edit` suffix only for a title or body edit, so those runs cancel only each other. A base move joins the normal group and cancels the stale run. </details> Screenshots: nothing on screen changed. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
ryanwelcher
added a commit
that referenced
this pull request
Oct 8, 2026
## Why Every release now needs `npm run i18n:download` in the version-bump PR. Skip it and the build ships old translations or none, and nothing fails. #546 documented the release without this step. translate.wordpress.org now has the project, and Polish is at 100%, so the next release will ship a catalog. ## What changes - `RELEASING.md` step 1 gains the download as sub-step 4: run it, commit `src/languages/`, and paste the coverage table into the bump PR. It says what is held back (right-to-left locales), what it prints when nothing qualifies, that it removes every other catalog in `src/languages/`, and that a failed run changes nothing. - The "exactly three changed lines" check now reads "outside `src/languages/`". - `RELEASING.md` step 3 says the Windows artifact may download with a `dist_` prefix, which has to be removed before it is attached to the release. - `CONTRIBUTING.md`'s "Back:" bullet links to the step, and loses the sentence saying translate.wordpress.org doesn't have the project yet. Not here: the CI check #543 suggests, which would fail a bump PR whose `src/languages/` doesn't match translate.wordpress.org. ## How to test this Platforms: any. Run from the repository root on this branch. 1. Read `RELEASING.md` step 1. Each claim in sub-step 4 matches `scripts/download-translations.cjs`. 2. Run `npm run i18n:download`. It writes `src/languages/pl.json` and prints a coverage table listing `pl`. Clean up with `git checkout -- src/languages && git clean -f src/languages`. 3. Click the `CONTRIBUTING.md#translatable-strings` link in `RELEASING.md` and the `RELEASING.md` link in `CONTRIBUTING.md`'s "Back:" bullet. Both land on the right heading. **What must not have happened:** no file outside `RELEASING.md` and `CONTRIBUTING.md` changes. Step 2's download removes any untracked catalog in `src/languages/`, so move one aside first if you want to keep it. ## Risks and limitations - The branch was rebuilt on trunk after #546 merged. It used to carry #544's commits from before it was squash-merged, which conflicted with trunk in 12 files. - Pre-PR review: 1 medium and 3 low findings, all fixed; 2 nits left. ## Related Fixes #543 together with #546. --- <details> <summary>Review outcome (required — see AGENTS.md)</summary> - **Review:** completed. Fresh-context Explore agent on `24086a8` against trunk `6d5f334`. - Medium, fixed: the step said `No locales downloaded.` prints when no locale is over 80%. It prints only when nothing ships, nothing is held back and nothing is removed. - Low, fixed: right-to-left locales are listed after the table under the plain-text `Not shipped:`, and only when they reach 80%. - Low, fixed: the download removes every other catalog in `src/languages/`, untracked ones included. - Low, fixed: a failed run leaves `src/languages/` unchanged. - Nits, left: the link could point at the subsection instead of `#translatable-strings`, and step 1's sub-steps now run to 6, which overlaps the section numbers. Nothing refers to them by number. - **Since review:** `24086a8 → 7ebde3f`: the four fixes above in step 1, and the `dist_` note in step 3. Not re-reviewed; both are docs only. - **CodeRabbit:** not requested. </details> 🤖 Generated with [Claude Code](https://claude.com/claude-code)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The release process isn't written down. The only documented step is the docs deploy in
CONTRIBUTING.md; the rest lives in people's heads and in past bump PRs like #533.What changes
RELEASING.mdwith six steps: bump PR, check the Buildkite artifacts, merge, publish the GitHub release with the tag, deploy the docs, close the milestone.CONTRIBUTING.md's "cutting a release" now links to it.The steps come from how v1.2.0 and v1.2.0-beta.2 were actually cut: #533's diff and checks, the release assets and flags, the
v1.2.0tag on the squash commit7afbb1a, and thedocs.ymldispatches.Deliberately not here: the
npm run i18n:downloadstep. That script only exists once #544 lands, so a stacked follow-up adds it. The CI check #543 suggests isn't in either PR.How to test this
Platforms: any. Nothing runs; this is a docs change. Read
RELEASING.mdagainst the last release:gh release view v1.2.0 --json assets -q '.assets[].name'from anywhere. The three names match step 2's list.git rev-parse v1.2.0from the repository root. It prints7afbb1a…, Bump version to 1.2.0 #533's squash commit, which is what step 4 says to tag.CONTRIBUTING.md#the-documentation-sitelink in step 5 and theRELEASING.mdlink inCONTRIBUTING.md. Both land in the right place.What must not have happened: no file other than
RELEASING.mdand one line ofCONTRIBUTING.mdchanges.Risks and limitations
7afbb1a's). If Buildkite also builds trunk and the files came from there, step 2 and 3 should say so.app.asarandCFBundleShortVersionStringchecks are copied from Bump version to 1.2.0 #533's post-merge checks; the doc moves them before the merge.Related
Part of #543. The translation step follows in a PR stacked on #544.
Review outcome (required — see AGENTS.md)
2 [fix here] · 0 [follow-up]. Both fixed.
vX.Y.Zmilestone for every release, but most betas had none. It now says "if the release has a milestone", and to leave the stable one open until the stable release.Also from the review's notes: past release notes end with a Downloads section. Step 4 says so now.
760de7bagainst base trunk0dc54da; outcome above.760de7b → 50e5455, the two fixes above. Not re-reviewed.npm run lintclean;npm test1676 tests (1674 pass, 2 skipped) on760de7b, and the later commit touches only Markdown.🤖 Generated with Claude Code