Write script / GitHub Action for backporting

[The-Compiler]

There is a lot of manual work involved when backporting a PR to a release branch. Ideally, that would only be required if there are conflicts to be solved.

Would be cool to have a script to prepare a backport PR. Then, as a next step, that could be integrated into GitHub Actions so that the "needs backport" label automatically causes a bot to backport the PR to the newest maintenance branch (either when a closed PR is labelled, or when a labelled PR is merged).

Maybe something suitable exists already, I can't imagine us being the only project who needs something like that. I know the Qt Company has something very similar (after I suggested it to them, though I didn't implement it). Theirs is based on their own CI and Gerrit, though.

[nicoddemus]

Definitely!

Just to comment that there's https://github.com/peter-evans/create-pull-request to create the actual PR.

[nicoddemus]

We probably can write everything in GitHub actions, without needing an auxiliary script.

For example we can trigger a workflow when a PR is merged:

https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request

closed: If the action is closed and the merged key is false, the pull request was closed with unmerged commits. If the action is closed and the merged key is true, the pull request was merged.

I have seen other projects have specific labels, say backport 7.0.x so the workflow would know to which branch it should be backported to.

[The-Compiler]

Agreed we can do it directly via Actions - but we already have scripts for other things we run there (e.g. preparing release PRs), and it also makes it easier to test things if we can run them independently.

As for the label, I suppose we could just use the newest release branch - it's quite rare that we want to backport to an even older release.

FWIW I use the peter-evans/create-pull-request action for qutebrowser though, quite happy with it!

[nicoddemus]

but we already have scripts for other things we run there (e.g. preparing release PRs), and it also makes it easier to test things if we can run them independently.

No problem. I'm not 100% convinced in this case TBH, feels like the "commands" to execute is just a single git command, and the tricky part is deciding when to trigger it, which seems easy to do directly with GitHub actions rather than implementing in a custom script which needs to call the API.

But I'm not against using a custom script if whoever implements this prefers that way of course. 😁

As for the label, I suppose we could just use the newest release branch - it's quite rare that we want to backport to an even older release.

Indeed, that's simple if we decide to use a custom script.

[bluetech]

👍 👍 👍 on this.

FWIW I use the peter-evans/create-pull-request action for qutebrowser though, quite happy with it!

We use it for the periodic plugin list updates, but for some reason it has a problem where the tests don't trigger for the PRs it creates, I don't remember why.

[nicoddemus]

It needs to be triggered by a Private Access Token or a GitHub bot unfortunately (there's more information on the docs for that action IIRC).