The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A pull request can pass its own checks and still fail in GitHub’s merge queue because the queue tests a different commit: the current target branch combined with the pull requests ahead of it and the queued pull request itself. To merge, the required checks must pass on that combined version. A green result on an earlier pull-request commit does not guarantee that outcome.
What the merge queue tests
GitHub processes queued pull requests in order and creates a temporary merge group for each one. The group includes the latest target branch and changes from pull requests ahead of the current entry. GitHub runs the required checks against that composed state; if they pass, the group can merge.
For example, if PR B is behind PR A, the temporary version tested for B can include the target branch, A, and B. If A is removed from the queue, GitHub can recreate B’s group without A. Moving an entry to the top can also rebuild groups already in progress. The code under test therefore changes as the queue changes.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
That is why “green” is revision-specific: it describes the code tested by a particular check, not every later combination that might include the pull request. GitHub’s documentation describes this merge-group behavior; it does not provide a failure-rate statistic for green PRs entering a queue.
#1 Best Overall
Why a green PR can fail after queueing
- The combined code behaves differently. New target-branch changes or earlier queued PRs may interact with the current PR and cause a test failure.
- The required workflow never runs for the queue event. A workflow listening only for
pull_requestdoes not automatically run formerge_group. Without a result, the required check remains unreported. - External CI ignores the temporary branch. The queue branch has a different SHA from the PR’s SHA. A CI provider configured only for ordinary PR branches may not run on it.
- A check is skipped, still pending, or reports failure. Path or branch filters and workflow conditions can prevent a required check from completing. A check may also fail on the combined code or exceed the queue’s wait period.
- The merge group conflicts or cannot meet branch protection. GitHub lists base conflicts and unresolved branch-protection failures among reasons an entry can leave the queue.
How to add merge_group to GitHub Actions
For a workflow that reports required status checks, include merge_group as an event trigger in addition to the events it already needs. For example:
on:
pull_request:
merge_group:GitHub documents merge_group as separate from pull_request and push. Adding it lets Actions run the workflow when a pull request enters a merge queue, so GitHub can receive the required result for the merge group.
If you use a third-party CI provider, configure it to run on pushes to temporary queue branches beginning gh-readonly-queue/{base_branch}. Use the queue branch’s commit SHA for that run rather than assuming it matches the pull request’s SHA. See GitHub’s merge queue documentation and the GitHub Actions merge_group event reference.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteDebug a queue failure in order
- Inspect the required check on the queued PR. Determine whether it is missing, pending, or failed. Check that its name and reporting source match the requirement configured for the target branch.
- Confirm the event reaches CI. In Actions, verify the workflow listens for
merge_group. In external CI, verify that queue temporary branches are included in its trigger rules. - Review filters and conditions. Check path and branch filters and any job-level conditions. GitHub warns that a skipped workflow can leave an associated required check pending. Keep required check names unambiguous across workflows; if branch protection specifies an app as the expected source, verify the result comes from that app.
- Check which commit the result covers. Required checks must succeed on the latest commit SHA. A green check for an earlier PR revision does not satisfy a requirement for a different queue commit.
- Inspect the merge-group changes. Review the current target-branch content and earlier queued PRs included with this entry. Look for interactions, failing tests, or conflicts that are absent from the PR’s standalone check.
- Read the PR timeline and queue timeout. The timeline shows why GitHub removed an entry. Check whether the queue stopped waiting before CI reported success.
GitHub’s guidance on required status checks covers check names, sources, and skipped workflows; its merge queue guide describes queue behavior and removal reasons.
Which merge-queue settings affect checks and throughput?
Repository administrators can require a merge queue through branch protection. GitHub documents settings for merge method (merge, rebase, or squash), maximum concurrent merge-group builds, whether groups can contain only non-failing pull requests, the status-check timeout, and minimum and maximum merge limits with a wait period. The documented concurrency and merge-limit ranges are each 1 to 100; these are configuration limits, not performance guarantees.
| Setting | What it controls | Trade-off to consider |
|---|---|---|
| Required-check strategy | Whether checks must pass for each queued PR’s merge commit or only for the combined group head. | More checks can provide per-PR validation but require more CI work. |
| Maximum concurrent merge-group builds | How many merge-group CI builds may run concurrently; GitHub documents a range of 1 to 100. | Higher concurrency can use more CI capacity; lower concurrency can limit simultaneous work. |
| Status-check timeout | How long the queue waits for required checks. | A longer wait accommodates slow CI but can delay queue progress; a shorter wait can remove entries before slow checks finish. |
| Minimum and maximum merge limits and wait period | When checked pull requests may merge together and the configured group-size limits; GitHub documents each limit as 1 to 100. | Group size and wait time affect merge timing and CI or deployment considerations. GitHub cautions that merge limits do not combine merge-group builds. |
The GitHub REST rules API documents two required-check grouping strategies: ALLGREEN requires each PR’s merge commit created by the queue to pass, while HEADGREEN requires only the head commit containing the combined changes to pass. Confirm which strategy applies to your repository’s ruleset before interpreting what a successful group check covers. See GitHub’s REST API documentation for repository rules.
How to add or remove a pull request from the queue
On GitHub, a contributor can select Merge when ready. If requirements are not yet met, GitHub can add the PR once they are. For a queue-required target, gh pr merge adds the PR when required checks pass and enables auto-merge if they have not passed yet. GitHub’s documented CLI guidance says to remove a queued PR on GitHub.com.
An entry can leave the queue after a merge-group check fails, the queue times out while waiting for success, a user requests removal, or a branch-protection failure cannot be automatically resolved. The PR timeline records the removal reason.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
