Merge queue checks workflows that were triggerd in pull request

[ezratameno]

Select Topic Area

Bug

Body

I have a workflow call-ci-workflow which contains 2 jobs that are required as status checks:

1. ci_start - indicate that ci has started
2. ci_done - indicate that all jobs passed successfully

We see this new behavior where in the merge queue for some prs the merge queue doesn't wait for the ci_done which was triggered by the merge group event but looks at the ci_done job triggerd by the pull request event as you can see in the image.

This issue cause so that PRs that didn't passed ci were merged.

The WA that we did was create a new job that waits for the ci_done job to finish successfully.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[dahel8]

We have also been seeing this behaviour since around the 5th of February as well. What we have concluded so far is that it seems to happen when the PR is up to date with the target branch. This can also be seen in the "Checks" tab of the PR where it now associates all workflows that was triggered for that commit, when up to date with target, regardless of its trigger (merge_group, push, release, etc.)

[nbdd0121]

It looks like GitHub now does a fast-forwarding merge when the PR is up-to-date with target branch. This causes the status checks on PR to be picked up, where previously the rebased commit will generate a new SHA so it won't pick up statuses on PR run itself.

[talcoh2x]

We are experiencing the same issue that has persisted over the last few days. Does anyone have a workaround for this?

[otto-liljalaakso-nt]

The workaround we will start using is to rebase to commit before master before merging. According to my testing, this works in our conditions:

git rebase --onto origin/master^ $(git merge-base HEAD origin/master)

[orschaup]

We are also seeing this issue since roughly 05.02.. We are finding it hard to reproduce the issue consistently, which is also making it difficult to verify that the proposed workarounds work in our case.

@ezratameno Can you elaborate further on the workaround you have found?

[talcoh2x]

Reproducing issues is straightforward. To do this, enable the merge queue with a merge policy set to Rebase.
Once a pull request is created with a branch that is already up-to-date issue reproduced.

The solution we discovered and that is currently effective involves using squash instead of Rebase. This approach resolves the problem and functions as it did previously.

[kaungzawhein543]

Bug Report: Merge Queue Skipping Required Status Check (ci_done)

Issue Summary

We have a workflow (call-ci-workflow) with two jobs required as status checks:

• ci_start - Indicates CI has started
• ci_done - Indicates all jobs have passed successfully

However, we are experiencing an issue where the merge queue does not always wait for ci_done triggered by the merge group event. Instead, it incorrectly considers the ci_done job triggered by the pull request event, leading to PRs being merged even when CI hasn’t fully passed.

Impact

• PRs that did not pass CI were merged.
• The merge queue is not consistently enforcing required checks.

Workaround

To mitigate this issue, we added a new job that explicitly waits for ci_done to complete successfully before allowing the merge to proceed.

Expected Behavior

The merge queue should always wait for the ci_done job triggered by the merge group event instead of incorrectly checking the one triggered by the pull request event.

Steps to Reproduce

1. Create a workflow (call-ci-workflow) with ci_start and ci_done jobs.
2. Require ci_done as a status check.
3. Open multiple PRs and add them to the merge queue.
4. Observe that in some cases, the queue considers ci_done from the pull request event instead of the merge group event.

Request for Fix

We suspect this might be an issue with how the merge queue associates required status checks with different workflow events. Could you confirm whether this is a known issue and if a fix is planned?

Thanks! 🙌

[otto-liljalaakso-nt]

GitHub support informs us that the change that caused this has been reverted. Out testing confirms that things have indeed returned to the earlier, good state.

Thank you for your patience as I discussed this with our engineering teams. This was an unexpected result of a change intended to reduce CI runs required if the HEAD SHA was already up-to-date. Since you, and others, reported that you had been relying on the previous behavior, we have rolled back this change and our plan is to make it a configurable option when we roll it out again in the future, though I can't promise when that will be.

I recommend watching the GitHub Changelog for updates on this, and thank you again for reporting this.

[xilingwu-stackadapt]

Hi!

Has the behaviour been reverted again? I'm seeing same issue where the merge queue depends on the check triggered by pull_request instead of triggering new run.

Our use case:
We need a action to perform some database operation after code enters merge queue, if those action are successful, the code can be merged, otherwise it will be removed from merge queue.
Previously since the action requires have both merge_group and pull request trigger for it to work, we added this ${{ github.event_name }} != 'merge_group' to bypass the trigger by pull request.
It has been working fine till recently we noticed the code is merged without waiting for merge queue trigger run, instead it will show passed check trigger from pull request.

[rkATmsk]

Same here, it doesn't display event of merge-queue, instead it display after merge.

[rkATmsk]

I don't know what new things has been introduced,
2 PR merge in Queue, start other merge-queue event after 10min. I set the concurrency for 2, but it start 6 workflow runs.

It was working well until day before yesterday.