Add merge workflow#22120
Conversation
|
|
||
| permissions: | ||
| contents: read | ||
|
|
There was a problem hiding this comment.
Add concurrency, this should not run concurrently.
https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency
| fetch-depth: 0 | ||
| filter: blob:none | ||
| ref: ${{ github.event.pull_request.base.ref }} | ||
| token: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
Please check that merging with GITHUB_TOKEN triggers CI for merged branches, This might need an app token.
| pull_request_target: | ||
| types: [labeled] |
There was a problem hiding this comment.
Using pull_request_target should be avoided. I would suggest using workflow_dispatch that gets triggered by a separate small workflow that runs on issues: labeled, validates the label/actor/PR, then calls the dispatch workflow.
| return try_run(['git', 'show-ref', '--verify', '--quiet', "refs/remotes/origin/$branch"]); | ||
| } | ||
|
|
||
| function find_next_release_branch(string $current): ?string { |
There was a problem hiding this comment.
This is great, but what if someone labels an old open PR targeting an unsupported branch by mistake and the automation goes off merging it. I would suggest we keep a manifest of branches that this goes through and that is maintained when we branch off to avoid any unexpected merges.
There was a problem hiding this comment.
I believe that should be rejected due to our push rules. But I'm happy to test.
| push_pr_branch($pr_repo_url, $pr_ref, $squashed_sha, $pr_sha); | ||
| push_release_branches($release_branches); |
There was a problem hiding this comment.
This is not atomic as what if pr_branch gets pushed and push_release_branches fails, this can happen when github is having issues which is a lot lately.
There was a problem hiding this comment.
Indeed, but sadly I didn't find a way to push both the PR and release branches atomically, given that the PR branch comes from a different origin. I thought this was acceptable, given that we sometimes do this manually as well.
The only solution I can think of is to revert the PR by pushing the previous commit, but given this might also fail, that would also be an incomplete solution.
Do you have another suggestion?
There was a problem hiding this comment.
I think adding error handling and a PR comment in case this goes wrong might be a good compromise.
| } | ||
|
|
||
| function push_pr_branch(string $url, string $branch, string $squashed_sha, string $original_sha) { | ||
| run(['git', 'push', "--force-with-lease=$branch:$original_sha", $url, "$squashed_sha:refs/heads/$branch"], |
There was a problem hiding this comment.
This might fail if the PR author forgets to tick the box to allow maintainer commits.
There was a problem hiding this comment.
Indeed. This step is technically optional, but I'm doing it so that the PR is marked as "merged". I suppose we can close it manually if this step fails, but I also don't think many people tick off this box. But I'm happy to add this fallback if you like.
There was a problem hiding this comment.
Yes, handling the fallback would be better.
There was a problem hiding this comment.
We'll need to differentiate between a force-with-lease failure and the missing checkbox. In the former case, we don't want the fallback. I'll see what I can do.
| PR_FIRST_SHA: $(git log --reverse --format=%H ${{ github.event.pull_request.base.sha }}..${{ github.event.pull_request.head.sha }} | head -n1) | ||
| PR_SHA: ${{ github.event.pull_request.head.sha }} | ||
| PR_REF: ${{ github.event.pull_request.head.ref }} |
There was a problem hiding this comment.
There should be a check to stop this workflow before pushing changes if the PR_SHA does not match the PR head as it changed between the label event and the workflow merging and pushing. This can happen when the nightly workflow is running and other workflows runs are delayed.
| id: merge | ||
| env: | ||
| PR_NUMBER: ${{ github.event.pull_request.number }} | ||
| PR_FIRST_SHA: $(git log --reverse --format=%H ${{ github.event.pull_request.base.sha }}..${{ github.event.pull_request.head.sha }} | head -n1) |
There was a problem hiding this comment.
This doesn't actually work ofc and will need to run and declared as an env there, or just moved to the script.
2 participants
TODOs:
Signed-off-byfrom the person adding the label, and potentially from approved PR reviews.Co-Authored-Byfor any other commiter.Feedback is appreciated. I know some people were skeptical of this approach (@TimWolla, @shivammathur), but I think it's worth trying out. @asgrim expressed interest in this, after seeing how many steps the merge process involves.
Simple test on my fork: