Merge Queue running checks twice?

[dbartholomae]

Select Topic Area

Product Feedback

Body

It seems that merge queues load to running checks twice: Once on the PR, and then again on the merge queue. While this is needed when multiple PRs are batched together, it isn't needed when there is only on PR in the queue. Is there a way to automatically skip checks in that situation?

[vitorhugods]

Also found on the main Merge Queue feedback thread:

#46757 (comment)

This behaviour makes me think of the Merge Queue as a complicated automation on the "Update branch with target branch" button.
At a cost that it will take twice as long to check when it's already up-to-date.

[aldenquimby]

Also found here: #48792

[supotrois]

[purajit]

That's not what the issue here is - the issue is that when a PR is already up-to-date and at head of queue, there's nothing to be gained from re-running the checks while it's in the merge queue.

[gnwosu]

+1

[kiriti-kumo]

Is there any update on this issue? We waste a lot of Github Action minutes because of this duplicate checks even when the branch is up to date.

[sloanesturz]

Hi @willsmythe any update on this bugfix?

It's been almost a year since the Merge Queue went GA and this issue is still open and affecting lots and lots of Github users.

[BenEaston]

Hey @willsmythe any update on this? We'd love to speed things up with the merge queue!
Thanks

[deepak-bala]

It's June 2024, and I still have this problem with my repos.

I use the following hack to skip jobs that run on the PR. Using an if condition to check which event triggered the workflow completely skips the job on the PR but runs it on MQ. If the workflow event is not merge_group, I don't run the job.

Skip with "if" condition

  unittests:
    timeout-minutes: 10
    if: ${{ github.event_name == 'merge_group' }}
    runs-on: ubuntu-latest-8-cores
    name: Unit Tests
    steps:
        << your steps go here >>

• You can also check if your branch is up to date with main on another job and use the needs attribute if you don't want to run a job without merging main first.
• To check if there are multiple PRs queued on the MQ, use the MergeQueueEntry property on the PR API and return its count on a job. Use the output of that job as an input to the if condition on your dependent job. This will let you tweak behavior when there's one PR in the queue vs multiple PRs.

[purajit]

As a note for people who might use this: this could cause issues since someone could merge a PR based on an old trunk that wouldn't pass tests on the new trunk, and it would be let in since the MQ skips it.

[deepak-bala]

You'll need to force your branch to be up to date with the branch you're merging to and make that a mandatory check before the PR can be allowed to merge into the queue. The code above skips the step in the PR but not on MQ.

[lesaux]

I don't really understand the use case for this behaviour.

I want status checks in my PR, but I don't think I need them a second time in my merge queue. That's just a waste of money.
I tried the opposite of above: i.e. skip the jobs in the merge queue with
if: ${{ github.event_name != 'merge_group' }}
But the skipped status is not considered a success, and the merge queue stays stuck.
I think the merge group/queue needs it's own configurable status checks.

[purajit]

If you have that if condition on a required check, you will need to create a duplicate check with the same name with if: ${{ github.event_name == 'merge_group' }} which always passes by returning true. GH is looking for an explicit success from a required check of that name. You may have to create a separate workflow file for this with a merge_group trigger.

But just as note, the only case where it's perfectly safe to do this is if the PR is both up-to-date with trunk, and there's nothing in the MQ. (If you're just looking to skip an entire workflow on MQ, that can be done with the above method, but that case is not what this discussion is about)

[chinanderm]

But the skipped status is not considered a success

Yes it is. From here: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks

Note: A job that is skipped will report its status as "Success". It will not prevent a pull request from merging, even if it is a required check.

[purajit]

Yes it is.

That's about what a skipped job behaves like, not a skipped workflow.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks#handling-skipped-but-required-checks