Add GitHub Action to automatically create cherrypick PRs

[tetrapod00]

Uses peter-evans/create-pull-request and actions/checkout, both of which are already dependencies.

When merging a PR with a cherrypick label, attempt to cherrypick a single commit into a new branch, then create a PR.

Handles squash and merge, by checking the number of commits in the PR, and choosing the commit to cherrypick accordingly.

Fails if the cherrypick does not apply cleanly.

Does not attempt to merge the new PR.
Does not attempt to update stable.

---

This will likely need to wait until we stop using stable, since each auto-cherrypicked PR would need a separate PR to update stable. We can definitely automate that with another action, and I think we can even make the second action trigger on merge of any of these automatic cherrypick PRs... but that seems very messy. If we wait until stable is no longer used, then these automatic cherrypick PRs can simply be merged after giving them a human review, and then will trigger a rebuild of the docs.

To test this I recommend making a new fake-master or similar branch in your fork, create a 5.3 branch and a cherrypick:5.3 label, and then change the relevant strings in the workflow file to refer to those branches instead. At least, that's how I tested.

Potential future improvements:

• Handle squash and merge PRs. The API doesn't explicitly expose a way to test how a PR was merged. But we can check the number of commits in the PR, and handle the two cases differently. This is prone to error if for example we squash and merge a PR with a single commit, or merge commit a PR with several commits. But I think that in those cases the cherrypick will not apply cleanly, and still fail. And there should be a human review for these auto-cherrypicks anyway.

Optional:

• Handle cherrypicking to multiple past branches. I ran into some limitations of the GHA syntax and couldn't figure out how to use an env variable within a contains(). So I couldn't figure this out in the initial implementation. There should be some way, though.
• Remove the cherrypick label automatically when the cherrypick is merged?
• Comment automatically when the cherrypick is merged?
• Comment in the PR if the cherrypick does not apply cleanly?

[mhilbrunner]

Yaaay! Exactly the direction I had in mind and never found time for.

This will likely need to wait until we stop using stable, since each auto-cherrypicked PR would need a separate PR to update stable.

Yes; but IMO it is fine to still sync stable automatically after merging a bunch of these PRs. Shouldn't block this.

Remove the cherrypick label automatically when the cherrypick is merged?

That'd be super nice, but not blocking IMO.

Comment automatically when the cherrypick is merged?

Nice to have but not critical to me.

Comment in the PR if the cherrypick does not apply cleanly?

Likewise not critical, as the absence of a cherrypick PR referencing it kinda already implies something went wrong.

Handle cherrypicking to multiple past branches.

Nice to have, but also harder to handle logically -- e.g., we still have many PRs labelled for cherrypicking to older branches that shouldn't be cherrypicked anymore now that current stable has moved on (a lot of enhancement PRs usually).

So personally I'd rather keep this manual, actually. Also, now that the team is growing we can hopefully move more towards anticipatory work (e.g. document the upcoming Godot versions before/as they come out), instead of having to catch up a lot. As we now get smaller, but more frequent releases it is also not as critical if some stuff is not, say, in 4.1 docs but in 4.2/4.3. This was a large issue in the past with the larger, slower releases.

So overall, we will probably be increasingly more conservative in what we cherrypick to old branches, and how far back, keeping that increasingly to important bug fixes (docs that are outright wrong or misleading, for example).

---

The only blocking things here to me are:

• This needs a bit of testing. Help welcome!
• We need to handle squash+merge cleanly, especially as we are increasingly using that now.
• Once we are happy with it, we need signoff by Akien, to make sure he's happy with how the Git history looks with this.

Thank you for working on this, this will make both the docs team and users super happy :)

[tetrapod00]

Squash and merge is now handled.

For the sake of code review, you may be interested in the GH docs for the ternary hack and for the pull request event:

Note that GITHUB_SHA for this event is the last merge commit of the pull request merge branch. If you want to get the commit ID for the last commit to the head branch of the pull request, use github.event.pull_request.head.sha instead.

[tetrapod00]

I think all the nice-to-haves will require one or more separate actions/workflows, which trigger on the merging of the automatically generated PR. I believe there is also a complication where PRs generated by actions usually don't trigger new actions to avoid recursion, unless you manually set it up.

So if this workflow of automatically generating but manually merging PRs is acceptable, let's defer the nice-to-haves for later.

[Repiteo]

Oh wow, this is a very interesting prospect! I'll be watching this closely, as it would be extremely useful to setup an equivalent on the main repo

[tetrapod00]

Applied those suggestions. Though ideally, no TODOs should remain after review is done.

For implementing this in the main repo, I see some potential obstacles:

• One cherrypick PR per actual PR may be unacceptably noisy for the main repo.
• In the main repo, the assumptions about commits per PR might not cleanly apply, since occasionally there are PRs with multiple commits that are merged without squashing at all (if each commit is valid).

On the other hand:

• The main repo does not have the complication of maintaining both a 4.3 and a stable branch.
• In the main repo, 99% of the time a PR does contain a single commit. So as long as those multiple commits are caught somehow, the code can overall be simpler by not dealing with squash and merges.