Add merge workflow#22120
Conversation
| 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.
| 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.
Merging should be fully sequential.
[remote rejected] is not reliably there.
Verified with PHPStan locally.
Pushing with GITHUB_TOKEN does not trigger CI. See: https://github.com/orgs/community/discussions/25702
| php "$RUNNER_TEMP/merge_pr.php" | ||
|
|
||
| - name: Report failure | ||
| if: failure() |
There was a problem hiding this comment.
| if: failure() | |
| if: ${{ failure() }} |
Dynamic variables should always use ${{ }} to keep linters happy. Applies to all if: conditions.
| }); | ||
|
|
||
| - name: Remove Merge label | ||
| if: ${{ always() }} |
There was a problem hiding this comment.
Should be:
| if: ${{ always() }} | |
| if: ${{ ! cancelled() }} |
There was a problem hiding this comment.
This was actually intentional, to make sure the label is always removed after the workflow stops. It's not a likely case, nor a big issue, but you'll then have to remove the label by hand to re-add it. If you feel strongly about this, I can change to ! cancelled().
Regarding this point. What do you think about a solution like https://github.com/changesets/changesets as a GitHub workflow? It helps with merge conflicts in CHANGELOG. The principle is that devs create separate files for each change, and the workflow collects those changes into one CHANGELOG file update: changesets/changesets#2085 |
4 participants
TODOs:
Co-Authored-Byfor any other commiter.Signed-off-byfrom the person adding the label, and potentially from approved PR reviews.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: