CI: Automate the "Tested up to" bump in readme.txt

[ramonjd]

What

A daily scheduled workflow that opens a pull request bumping the Tested up to field in readme.txt when a new WordPress version becomes the latest stable release.

Why

The field only changes today inside the manual "bump minimum required WordPress version" chore, which lands weeks after the WordPress release. In between, nothing notices the gap: the performance workflow reads the field on every trunk push and release, so a stale value quietly pins those runs to the old wp/X.Y branch. Right now the version check API already reports 7.1 while readme.txt says 7.0, so the first run after merge will open the 7.1 bump.

What changed

• New bump-tested-up-to.yml workflow: daily cron plus manual dispatch, restricted to WordPress/gutenberg.
• The check runs first against a sparse checkout of readme.txt with no credentials. The write-scoped app token is only minted when there is something to push, and the app-created pull request triggers CI (the default GITHUB_TOKEN would not).
• readme.txt may legitimately run ahead of the API (it can name an upcoming release), so only an older value triggers a bump, and only once the wp/X.Y branch exists.
• Deduplication keys on the pull request record rather than the branch: a closed pull request counts as a human decision and is never re-proposed, while a leftover branch from an interrupted run is overwritten.
• A network failure in the branch checks fails the run instead of reading as "branch missing".
• The generated pull request body names the merge prerequisites: CI on the new WordPress version, and the REFERENCE_COMMIT update that docs/explanations/architecture/performance.md requires for every Tested up to change.

Manual testing

The workflow only runs on WordPress/gutenberg, so exercise the check logic locally:

1. Run curl -sf https://api.wordpress.org/core/stable-check/1.0/ | jq -r 'with_entries(select(.value=="latest"))|keys[]' | cut -d. -f1,2 and note it prints 7.1 while readme.txt says Tested up to: 7.0.
2. Run git ls-remote --exit-code --heads origin wp/7.1 and confirm it exits 0.
3. Run gh pr list --head update/tested-up-to-7.1 --state all and confirm it is empty, meaning a scheduled run today would open the 7.1 bump pull request.
4. After merge, trigger the workflow from the Actions tab and check it opens that pull request with both labels and the prerequisites in its body.

Notes

• The app needs pull request write permission. The token step fails cleanly if the installed app does not grant it.
• A release-time staleness warning for build-plugin-zip.yml was drafted and reverted on this branch to keep concerns separate. It can follow as its own pull request.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}

[Mamaduka]

Maybe we should keep this process manual; we also do a lot of cleanup after bumping versions, which might be hard to automate - #82404.

[ramonjd]

Fair enough. The bump was missed in the last release: https://wordpress.org/support/topic/latest-version-of-gutenberg-2/

Maybe there could just be a non-blocking check with warnings when building the RC instead?

Happy to close this, was just a YOLO experiment

Thanks!

[Mamaduka]

Maybe we should add this as a post-release task for someone who will handle the plugin after the WP release.

IMO, it's fine if version bumps happen a week or two later.