Release automation: try cherry-picking automation

[ellatrix]

What?

The idea is to have a designated label Backport to WP 6.6 Beta/RC and once a PR against trunk is merged with that label, it automatically cherry-picks that PR into the right release branch, removes the label, and comments on the PR. It should also work if the label is applied after merge. If there is a conflict, it will comment on the PR to make a PR against the wp/* manually.

Why?

Cherry-picking can be tedious, and it would be good to cherry-pick as soon as PRs are merged into trunk. That way conflicts can be detected and addressed early.

How?

See the workflow for details in logic.

To see it in action, this is the latest version: #62735 (comment)

Also, jobs will wait for the last one to finish so the checkout are always fresh.

Testing Instructions

I will attempt to create two branches that are based on this one:

• wp/0.0, to test if PRs get cherry-picked.
• try/cherry-pick-automation-trunk to simulate trunk.

Then I will create a few PRs against try/cherry-pick-automation-trunk to test if they get cherry-picked:

• ✅ One applying the label before merge: [Ignore] Testing #62716 (no conflict, add label before merge) #62731
• ✅ One applying the label after merge: [Ignore] Testing #62716 (no conflict, add label after merge) #62735 (comment)
• ✅ One with a conflict. It works: [Ignore] Testing #62716 (with conflict) #62724 (comment)

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ellatrix <ellatrix@git.wordpress.org>
Co-authored-by: vcanales <vcanales@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Flaky tests detected in 37d701f.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9609625039
📝 Reported issues:

• [Flaky Test] Navigates from items list to preview via TAB, and vice versa #62434 in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js

[vcanales]

LGTM. I like the requirement of creating PRs to the wp/* branch in order to merge changes that had caused conflicts.

[desrosj]

This is really neat! Thanks for this, @ellatrix.

I did make one small adjustment to the syntax for the versions of third-party actions to use in #62836. When possible we should use full commit SHAs as an extra level of hardening to be safe. The actions/checkout was also a few versions behind, but Dependabot took care of that for us.

[ellatrix]

Sounds good, thanks!

[gziolo]

This is awesome! One question, who decides about adding Backport to WP 6.6 Beta/RC label? On the technical level, the commit can always get reverted from the release branch if the release squad disagrees, so maybe it is not an issue at all.

[gziolo]

It could also get extended to backporting to the Gutenberg plugin release branches when there is a bug fix to land during RC or after the final release. At that point, we could delete the old bin/cherry-pick.mjs script crafted by @adamziel long time ago 😀

[ellatrix]

Yes, anyone who can add labels can add it. Th Editor Tech Leads should double check the commits before publishing packages, revert if they disagree with something. They would have to do this previously as well, but before cherry-picking. Tbh, I don't think it's a big deal, we should put trust in people and correct/ping if needed.

[gziolo]

Tbh, I don't think it's a big deal, we should put trust in people and correct/ping if needed.

Agreed. I guess it was the experience in the WP 6.6 release cycle so it's best to repeat it in the future 👍🏻