Build: Script to bulk cherry-pick patch PRs

[shilman]

Closes N/A

What I did

Publishing one of the helper scripts I use to patch back PRs from next to main.

The script:

1. queries for PRs marked with patch label but without picked label.
2. lists all the PRs and confirms with the user whether to pick
3. for each PR, it tries to cherry-pick the PR's merge commit to the current branch
   • if the cherry-pick succeeds without merge conflicts, it labels the PR as picked
   • if it fails, it aborts the cherry-pick and continues
4. at the end, it summarizes the run, making it easy to go back and manually cherry-pick the PRs that didn't make it over automatically.

It also supports a --documentation flag to limit the run to documentation-only PRs.

How to test

Set a GH_TOKEN environment variable with your user token.

cd scripts
yarn ts-node ./pick.ts

NOTE: this will cherry-pick the PRs to the current branch, so be prepared to roll it back and manually unlabel the PRs if you let it run.

[JReinhold]

This isn't quite what I had envisioned, I had thought about something more automatic and self-maintaining, via two GitHub Actions, that is a combination of this and Changesets. I'll try to describe it here, but maybe we need a call to go into more detail and make me re-think it (my approach might be completely wrong here, I haven't thought deeply about this yet).

1. Action that creates release PR

1. Run on every push to next
2. Create a release branch to be merged into main, like release-main
3. Find all PRs to next with "patch" label (like this script)
4. Cherry pick each merge commit individually (like this script)
5. If successful, commit to the release-main branch
6. If merge conflicts, skip and move on to the next PR
7. Bump all versions where applicable (like in package.json and versions.ts)
8. Updates CHANGELOG.md
9. When done, force push branch, overriding any previous runs of this
10. Open a PR from release-main to main (or update existing), with a list of cherry picked PRs, and a todo list of PRs that couldn't be cherry picked, with clear instructions on how to do that manually - with a git command for each commit

2. Manual releaser work

When release is due, the releaser:

1. goes through the manual todo list to merge the remaining PRs manually
2. commit and push the changes to release-main
3. QA the branch (not sure what this is yet)
4. Merges it into main

3. Action that publishes the new version

1. Run on every push to main (ie. when step two above is done)
2. Check if package versions are different from what is already on NPM
3. If they are, publish to NPM
4. Wait a bit, and check that versions have been published, and possibly retry if some failed
5. Create a GitHub Release

---

This is a bit more automatic and self-updating, only requiring manual intervention when cherry-picks results in merge conflicts (I don't fully understand how that happens, but I trust that it is a real thing). If the majority of cherry picks need to be handled manually, this might not make sense at all, but I get the sense that it's in the 10 % - 20 % range?

Another caveat here is that the releaser could be in the process of doing step two, and then the action from step one does a new force push, possibly screwing up the releasers work. We might need a way to cancel the action, perhaps a "freeze" label on the release PR or something else to signal to the action.

[shilman]

@JReinhold please feel free to implement what you've described. I just wanted to make the script I currently use to do the release available in the monorepo for anybody to use.

[shilman]

Closing since this has been redone by @kasperpeulen already