Add github action for backporting PRs #32777
Conversation
| // extract the target branch name from the trigger phrase containing these characters: a-z, A-Z, digits, forward slash, dot, hyphen, underscore | ||
| const regex = /\/backport to ([a-zA-Z\d\/\.\-\_]+)/; | ||
| target_branch = regex.exec(context.payload.comment.body); | ||
| if (target_branch == null) throw "Error: No backport branch found in the trigger phrase."; |
There was a problem hiding this comment.
Suggest enforcing /\/backport to release\/\d\.\d(-preview\d)?/ to avoid garbage \backport to freddy PRs.
Nit: could just ignore poorly-formed comments i.e. anything that doesn't match the full regular expression.
| pr_description_template: | | ||
| Backport of #%source_pr_number% to %target_branch% | ||
|
|
||
| /cc %cc_users% |
There was a problem hiding this comment.
Am I correct %cc_users% are the person who issued the /backport comment and the author of the containing PR (if distinct)❔ If possible, would be good to at least /cc the PR approvers on the backport PR. Of course, the original author must approve because the should understand whether a fix in 'main' is sufficient without additional work in (say) 'release/2.1'.
Separately, this action doesn't check group membership until fairly late. What is the visible failure if someone w/o rights to create branches in dotnet/aspnetcore adds a /backport to george comment❔
|
|
||
| jobs: | ||
| backport: | ||
| if: github.event.issue.pull_request != '' && contains(github.event.comment.body, '/backport to') |
There was a problem hiding this comment.
Should we confirm the PR has been merged before allowing backports❔
| pr_description_template: | ||
| description: 'The template used for the PR description. Special placeholder tokens that will be replaced with a value: %target_branch%, %source_pr_title%, %source_pr_number%, %cc_users%.' | ||
| default: | | ||
| Backport of #%source_pr_number% to %target_branch% |
There was a problem hiding this comment.
If possible, would appreciate the final commit hash in this comment
|
|
||
| if (error.postToGitHub === undefined || error.postToGitHub == true) { | ||
| // post failure to GitHub comment | ||
| const unknown_error_body = `@${comment_user} an error occurred while backporting to ${target_branch}, please check the run log for details!\n\n${error.message}`; |
There was a problem hiding this comment.
Where would users find the "run log"❔
| // download and apply patch | ||
| await exec.exec(`curl -sSL "${github.context.payload.issue.pull_request.patch_url}" --output changes.patch`); | ||
|
|
||
| const git_am_command = "git am --3way --ignore-whitespace --keep-non-patch changes.patch"; |
There was a problem hiding this comment.
I understand using the patch allows for back-porting an in-progress PR but
- It's not clear to me we want to support in-progress PRs in our repos. Would appreciate others' thoughts on this…
- It loses any separation the original author chooses to leave when merging e.g. they might rebase 2 or 3 commits rather than squashing them.
Do the available APIs support determining the final commit or commits when a PR is merged❔
|
/cc @dotnet/aspnet-build and @dotnet/aspdoi |
|
Other thoughts:
|
|
deferring most of these questions to @akoeplinger who wrote this code - we're considering moving this to arcade so it may make more sense to work on improvements as we do that. Though Doug does bring up some good points about extensibility, like the ability for repos to specify aliases to tag on these PRs & add them to repo projects. |
Pilchie
added
the
area-infrastructure
ghost
added this to the
|
Got this in because I wanna use it 🥇 |
These can be triggered with comments like
/backport to release/5.0@dotnet/aspnet-build any thoughts on a good place to document this feature?