"Checks failed" but not removed from the Merge Queue

[BriceMortier]

Select Topic Area

Question

Body

Hello,

GitHub version: 3.13.7

We observe an unexpected behavior with the merge queue: a PR receives a status failed but it is not removed from the queue.

We use the following merge queue configuration (note that Only merge non-failing pull requests is checked):

Any idea why this second PR is kept in the queue? It is only removed after the first is merged but it has the impact of invalidating the third PR build which needs to be rettrigered.

Regards

[ronaldotantra]

The issue you’re experiencing, where a pull request (PR) with failing checks remains in the merge queue despite the “Only merge non-failing pull requests” option being enabled, can be influenced by several factors. Here are some steps to diagnose and potentially resolve the problem:
1. Check Required Status Checks Configuration:
• Ensure that the failing check is listed as a required status check in your repository settings. GitHub uses this list to determine if a PR meets the necessary criteria for merging. If a failing check isn’t marked as required, the merge queue might not automatically remove the PR.
2. Review Branch Protection Rules:
• Navigate to your repository’s settings and examine the branch protection rules for the target branch. Confirm that the rules are correctly configured to enforce required status checks before merging.
3. Understand Merge Queue Behavior:
• The merge queue may have specific behaviors regarding failing checks, especially if the checks are optional or not explicitly required. It’s essential to differentiate between required and optional checks, as the queue might allow PRs with failing optional checks to remain.
4. Consult GitHub Documentation:
• Refer to the Managing a merge queue documentation for detailed information on how GitHub’s merge queue handles PRs with failing checks.
5. Contact GitHub Support:
• If the issue persists after verifying the above configurations, consider reaching out to GitHub Support for further assistance. They can provide more in-depth analysis and help identify any underlying problems with the merge queue behavior.

By systematically reviewing these areas, you should be able to identify the cause of the issue and implement the necessary changes to ensure that PRs with failing checks are appropriately managed by the merge queue.

[BriceMortier]

Thank you Copilot

[BriceMortier]

Hello,
I confirm all those criteria are met in the configuration. The failing status is Required and the configuration Require status checks to pass before merging is checked. Still the issue is there.

[BriceMortier]

I got my answer by testing. The build of the second pull request could have failed because of the changes of the first pull request. GitHub is then basically waiting for the status of the first pull request. And depending on the result:

• 1st PR also fails => 1st PR is removed and 2nd/3rd PR is retriggered
• 1st PR is successful => 1st PR is merged, 2nd PR is removed and 3rd PR is retriggered