Repository navigation
gh pr merge --auto doesn't wait for checks to complete #8514
Agent suggestions
Public previewDescription
Activity
Sorry for the long delay in responding here after Christmas. Some team churn a large backlog.
Can you confirm that this still occurs for you, and if so, can you provide the output of
gh pr merge --autowithGH_DEBUG=apienv var set?No prob. I haven't seen this work yet. I don't want to merge PRs that haven't had their checks pass. I noticed that if I add more CLI flags to the command the problem doesn't happen. But, if I just use
--auto, it always happens.$ gh --version gh version 2.44.1 (2024-02-16) https://github.com/cli/cli/releases/tag/v2.44.1I don't want to merge PRs that haven't had their checks pass.
Totally understand.
I noticed that if I add more CLI flags to the command the problem doesn't happen. But, if I just use --auto, it always happens.
That's pretty interesting. Looking forward to the debug logs!
Perhaps you could also provide a debug log with other flags so we can compare the requests/responses.
We also seem to have this issue, although maybe I just misunderstand the
--autofeature. Debug log attached (slightly redacted---can supply OOB if required). We are using rule sets that require all status checks to pass and interestingly(?) they are shown as 'passed', so possibly the problem is not the auto merge, but the build config?6_Auto-merge development dependencies.txt
I noticed that if I add more CLI flags to the command the problem doesn't happen
We're having this issue as well. What flags were you using when it didn't happen? Thanks @khatchad.
I noticed that if I add more CLI flags to the command the problem doesn't happen
We're having this issue as well. What flags were you using when it didn't happen? Thanks @khatchad.
gh pr merge --auto --delete-branch --squashgh pr merge --auto --delete-branch --merge
Reacted by EvanLooks like this problem has gotten worse. On gh version 2.48.0 (2024-04-17), I just tried
gh pr merge --auto --delete-branch --merge, and the problem happened with those arguments as well.Reacted by Yi Liu and GideonI wonder if this problem has something to do with
--delete-branchnow. I would think it would be difficult to "Delete the local and remote branch after merge" if--autois also specified.2 remaining items
we are facing the same issue.
Reacted by vi and Martin MajlisI had the same expectation as the original author. Based on the documentation I had enabled -
Require status checks to pass before merging. After explicitly mentioning all the checks that are required, it's now working as expected.So the confusing part is the settings UI, where my expectation was - "All checks has to pass". But it is - "Mentioned checks has to pass" - and you start with empty list, so there are no checks.
If you use large test matrix, then it requires lot of clicking.
Reacted by Joacim de la MotteWow, sorry, this just came across my radar again. I think there might be a number of different unexpected merges going on here that aren't all the same. I'll just note down the first one that seems relatively clear for the moment.
Unstable Hypothesis
Looking at the logs in #8514 (comment) and this comment about status checks #8514 (comment) I'm inclined to believe this is both "working as intended" and "kinda confusing".
The logs show that the PR was in
UNSTABLEmerge state:2024-04-09T22:24:13.6064341Z "data": { 2024-04-09T22:24:13.6064653Z "repository": { 2024-04-09T22:24:13.6064901Z "pullRequest": { 2024-04-09T22:24:13.6065341Z "id": "PR_kw<REDACTED>", 2024-04-09T22:24:13.6065883Z "number": 3326, 2024-04-09T22:24:13.6066315Z "state": "OPEN", 2024-04-09T22:24:13.6067171Z "title": "chore(dev): Bump eslint from 8.57.0 to 9.0.0 in the lint group", 2024-04-09T22:24:13.6067968Z "commits": { 2024-04-09T22:24:13.6068521Z "nodes": [ 2024-04-09T22:24:13.6068931Z { 2024-04-09T22:24:13.6069186Z "commit": { 2024-04-09T22:24:13.6069823Z "oid": "dc<REDACTED>" 2024-04-09T22:24:13.6070388Z } 2024-04-09T22:24:13.6070614Z } 2024-04-09T22:24:13.6070826Z ] 2024-04-09T22:24:13.6071125Z }, 2024-04-09T22:24:13.6071370Z "mergeStateStatus": "UNSTABLE", 2024-04-09T22:24:13.6071706Z "headRepositoryOwner": { 2024-04-09T22:24:13.6072394Z "id": "MD<REDACTED>", 2024-04-09T22:24:13.6073013Z "login": "RestSuper" 2024-04-09T22:24:13.6073451Z }, 2024-04-09T22:24:13.6074101Z "headRefName": "dependabot/npm_and_yarn/lint-2b738a81af", 2024-04-09T22:24:13.6074649Z "baseRefName": "main", 2024-04-09T22:24:13.6075164Z "headRefOid": "dc<REDACTED>", 2024-04-09T22:24:13.6075729Z "isInMergeQueue": false, 2024-04-09T22:24:13.6076267Z "isMergeQueueEnabled": false 2024-04-09T22:24:13.6076705Z } 2024-04-09T22:24:13.6076889Z } 2024-04-09T22:24:13.6077081Z } 2024-04-09T22:24:13.6077266Z }I believe this state is used to indicate "there are some issues with this PR but nothing that blocks the merge". The docs say:
Mergeable with non-passing commit status.
So for example, if you had a failing check that was not marked as required, it could be marked as
UNSTABLE.With the previous comment noting that marking these checks as required causes
--autoto work correctly, this seems like a reasonable hypothetical.
The Code
Right here we say that
UNSTABLEmeans that the PR is mergable right now. This is used to mark the entire merge as not automergable, which means that we issue a merge mutation rather than an auto merge mutation.
What can we do to make this clearer?
I'm not sure right now, the help text for this flags says:
--auto Automatically merge only after necessary requirements are metWhich is true but obviously there's enough people being tripped up by this that it's not sufficient.
Open to feedback!
I wonder if this problem has something to do with --delete-branch now. I would think it would be difficult to "Delete the local and remote branch after merge" if --auto is also specified.
Looking at the code, this flag is ignored if we are auto merging, which also doesn't seem very clear at all.
Hi! I'm facing similar issues.
I have different workflows that deploy different services. The last step of all workflows is the same:
SUCCESS-CHECK: needs: [RUN-TEST-CASES, PRODUCTION-DEPLOYMENT, STAGING-DEPLOYMENT] runs-on: ubuntu-22.04 name: Success check if: always() steps: - name: Decide whether the needed jobs succeeded or failed uses: re-actors/alls-green@cf9edfcf932a0ed6b431433fa183829c68b30e3f with: jobs: ${{ toJSON(needs) }}This last step is marked as required, so it must be successful in order to perform the merge, and since it is present in all worflows, it is executed once per service.
My problem is that when activating the automerge, if the first
Success checkjob of any workflow is successful, the PR is merged regardless of the result of the other ones, while other workflows are still running.
I understand that this could be fixed by using a different name for each
Success checkjob, but it is not a scalable solution.Reacted by Yurii SerhiichukHey @matimercado,
I think I understand your problem. It seems like your issue is that you have many jobs that share a name and the GitHub platform isn't able to disambiguate which one you meant to mark required? Is that right?
If so, I'm not sure there's anything we can do about it in
gh, since that is all platform side configuration. I could definitely pass on your feedback to the team though.Reacted by Yurii SerhiichukThanks for your answer @williammartin.
Something like that, it seems that GH is not able to detect that the job is going to be executed more than once, so if the first job that finishes is successful, the PR is merged. As you see, I can then observe both jobs where one failed and the other did not.
I would need that even if auto merge is enabled, it always waits for all jobs to finish.Really appreciate if you can pass on the feedback to the team.
Thanks again :)
are there any updates on this issue?
There's quite a lot of noise in this issue with a number of different possible underlying causes. Best if you provide debug (GH_DEBUG=api) logs and maybe we can pick it up again, thanks.
Could we set up separate issues for the known causes, to disambiguate them from each other and from unknown causes?
Personally I'd love for
--autoto accept an optional value that specifies that merging should only happen when all checks pass, not only required checks.Reacted by Jarkko MönkkönenThis is a confirmed bug report:
gh pr merge --autois merging the PR immediately instead of enabling auto-merge mode and waiting for required checks to pass, which contradicts the documented behavior ("Automatically merge only after necessary requirements are met"). No exact duplicate was found - a related issue #3514 discusses confusing--autobehavior from a different angle (doing nothing when checks already passed) but is not a duplicate. Given the 13 upvotes and 19 comments indicating wide impact, and the risk of unintended merges in CI workflows, I'm suggesting thepriority-2label in addition to the existingbuglabel.Generated by Issue Triage (skills-driven) · 23.3 AIC · ⌖ 6.14 AIC · ⊞ 5K · ◷
Going to close this out due to staleness and housekeeping. The challenge with this situation is that it's likely largely due to how the API behaves with regard to auto merging. Auto merging isn't much of a client side feature here - we just indicate in the API call to auto merge.
If there's a specific recent reproducible case that people keep running into, let's start a fresh issue and be sure to include the
GH_DEBUG=apioutput for us to investigate 🙏
Describe the bug
When I issue
gh pr merge --auto, the PR merges even though the checks haven't completed. It would seem to me that the command is ignoring the--autoflag. The version ofghI am using is 2.40.1.Steps to reproduce the behavior
gh pr merge --autoExpected vs actual behavior
I expect the PR to go into auto merge mode, i.e.,, to merge once the checks complete. The docs say:
for the flag
--auto.Instead, the PR merges with the checks still running.