github: add actions to automate backporting fixes #4162
Conversation
|
Example: |
|
I had a quick look to see if any existing Actions might do something similar, but they all appear to merge/rebase an entire PR rather than allow control over specific commits. (Introducing the use of milestones would be a good improvement regardless.) |
|
FWIW, I just found a small issue in this script, which I reported upstream at llvm/llvm-project#109429. |
This adds support for automatically cherry-picking fixes for the release branch using a special 'command' in comments: /cherry-pick <commit1> <commit2> ... This command attempts to cherry-pick the specified commit(s) to the release branch based on the milestone linked to the issue or pull request. If the commit(s) fail to apply cleanly, then a comment with a link to the failing job will be added to the issue/pull request. If the commit(s) do apply cleanly, the changes will be pushed to a new branch on GitHub, from which a pull request will be created.
f296898 to
cd6b8d5
Compare
Another point worth discussing is the process for updating changelog notes for patch versions. Should this be done gradually (e.g. as part of the backport or as a separate commit)? Or all at once as part of the patch release? FWIW, GLib does the latter (see e.g. commit GNOME/glib@bd40fbb). However, these changes do not seem to be reflected in the main branch (see e.g. https://github.com/GNOME/glib/blob/main/NEWS). |
This adds support for automatically cherry-picking fixes for the release branch using a special 'command' in comments:
This command attempts to cherry-pick the specified commit(s) to the release branch based on the milestone linked to the issue or pull request. If the commit(s) fail to apply cleanly, then a comment with a link to the failing job will be added to the issue/pull request. If the commit(s) do apply cleanly, the changes will be pushed to a new branch on GitHub, from which a pull request will be created.
Context: #4158 (comment).
Opened as draft as this needs some discussion first. We probably also need to treat release branches as distinct branches after this lands (i.e. the 8.x branches do not need to be merged back into the master branch).