Repository navigation
CI: Auto cherry-pick to Gutenberg release branches - #78879
Open
cbravobernal wants to merge 3 commits into
Open
cbravobernal wants to merge 3 commits into
cbravobernal wants to merge 3 commits into
Conversation
cbravobernal
added
[Type] Build Tooling
cbravobernal
added
[Package] Project management automation
Mamaduka
reviewed
Jun 3, 2026
| # Using pull_request_target instead of pull_request so that the workflow | ||
| # has access to repository secrets for fork PRs. | ||
| # https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target | ||
| pull_request_target: |
Member
There was a problem hiding this comment.
After recent events in the security world, are we still using pull_request_target?
Contributor
Author
There was a problem hiding this comment.
We are still using it. And the script is meant to run only in already reviewed and merged PRs. But happy to have a second opinion. @pkevan may help us?
Contributor
|
Would it be better to also support "Backport to Gutenberg Minor Release" as well? |
Contributor
Author
Gutenberg Minors are usually less common than cherry-picking to RCs before a point release, maybe we could do it in a different PR. |
Mirror the existing WP Auto Cherry-Pick workflow for Gutenberg's own release branches. On merge of a PR labeled `Backport to Gutenberg RC`, cherry-pick the merge commit onto the highest `release/X.Y` branch, push, remove the label, and comment the target branch + cherry-pick SHA. The Gutenberg backport label is versionless (the two-week cadence makes a per-release label impractical), so the target branch is resolved by semver-sorting `release/*` and picking the highest. Conflicts post a manual-resolution comment, matching the WP workflow. This removes the need for manual cherry-pick PRs like #78848 for the label-driven picks. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
cbravobernal
force-pushed
the
add/auto-cherry-pick-gutenberg-release
branch
from
October 14, 2026 13:58
34570aa to
f495e7d
Compare
github-actions
Bot
removed
the
[Package] Project management automation
🤖 PR meta 🤖🎉 PropsUnlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @gutenbergplugin. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. Updated as activity occurs, without notifying anyone named here. Add the |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
- Only resolve plain release/X.Y branches; scratch branches like release/24.2-cherry-pick sorted above release/24.2 and would be picked. - Filter in the job-level `if` and move concurrency to the job, so unrelated trunk merges no longer replace a pending backport run, and adding an unrelated label no longer retries a conflicted cherry-pick. - Pass values through step outputs and `env` instead of GITHUB_ENV. - Set the release milestone, as `npm run other:cherry-pick` does. - Bump actions/checkout to v7.0.1 to match the other workflows. - Document the workflow in the plugin release guide. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
cbravobernal
requested review from
fabiankaegy and
juanmaguitar
as code owners
October 14, 2026 14:06
zizmor flags pull_request_target as a dangerous trigger, and it gives the job write tokens on events any PR author can trigger. Run on push to trunk, on a 15-minute schedule, and on demand instead, and cherry-pick every merged PR that still carries the backport label, in merge order. - Works the same for fork PRs, and picks up labels added after merge. - Pushes before touching any PR, so a failed push leaves every label in place for the next run. - Leaves a hidden marker in the conflict comment, so a conflicting PR is commented on once per release branch instead of on every run. - Removes the label when the change is already on the branch. - Clones the repository only when there is something to pick. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
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.
What?
Adds
.github/workflows/cherry-pick-gutenberg-release.yml, which automatically cherry-picks PRs labeledBackport to Gutenberg RConto the current Gutenberg release branch.It runs on every push to
trunk, every 15 minutes, and on demand (workflow_dispatch). Each run:release/X.Y. Only plainX.Ynames count, so scratch branches likerelease/23.5-cherry-pickare ignored.trunkthat still has theBackport to Gutenberg RClabel, and cherry-picks them in merge order.Gutenberg X.Ymilestone (asnpm run other:cherry-pickdoes, so the changelog picks it up), and comments with the target branch and cherry-pick SHA.Why?
Today these picks are done by hand. For example, #78848 opened a manual cherry-pick PR onto
release/23.3. This automates the label-driven picks, the same way WP backports are already automated.Design notes
pull_request_target. Following the review discussion and zizmor'sdangerous-triggersrule, the workflow never runs in the context of a PR. Instead of reacting to PR events, it sweeps for labeled PRs, like the manual script does. This works the same for PRs from forks and picks up labels added after the merge. The trade-off is that a label added after the merge waits up to 15 minutes. That's fine for RC picks.Backport to WP X.Y Beta/RC) impractical, so the target branch is resolved instead. The chosen target is in the PR comment, so a wrong target (e.g. a label applied after stable shipped but before the next branch is cut) is easy to spot.GUTENBERG_TOKENsecret, which bypassesrelease/*push protection (the restriction Backport to 23.3: 10 cherry-picks for stable #78848 worked around).GITHUB_TOKENonly getscontents: readplus issue/PR write.Not covered (still manual)
Backport to Gutenberg Minor Release; can follow in a separate PR.Testing
Dry-run locally with both embedded scripts in a harness: real read-only GitHub API calls, real
gitin a scratch worktree, push and PR writes stubbed.release/24.2and found the 5 currently labeled PRs (Icons: Experiment with proportional stroke scaling #84081, Global Styles: Ignore theme.json values of unexpected types #84523, React 19 codemod: apply defaultProps when rendering a memo component #84568, React 19: add new incompatible plugins #84607, Experiments: don't invalidate saved option with a legacy key #84619) in merge order.release/24.2with milestoneGutenberg 24.2. Rerunning one already-applied PR took the "already on the branch" path. A conflicting commit took the conflict path, posted the marked comment, and left the branch clean with no push.Needs a maintainer to watch the first real run after merge. On its first run it will pick up whichever PRs carry the label at that point.
🤖 Generated with Claude Code