Unable to "Merge without waiting for requirements to be met (bypass rules)"

[CoreyKovalik]

Duplicate issues

• Bypass merge requirements not working on stacked PRs #186
• Allow "Merge without waiting for requirements to be met (bypass rules)" #226

Desired outcome

Have the same functionality to "Merge without waiting for requirements to be met (bypass rules)" for GitHub Stacked PRs.

The problem & reproduction

"This stack is out-of-date with its base branch

When a PR at the bottom of the stack is out-of-date with the base branch (main in this case) and is approved, you can merge it if your branch protections allow you to do so. All PRs above it in the stack lose their approval due to the rebase (this is expected).

Switching over to the next PR in the stack that has now become the bottom of the stack, it's unapproved (which is expected), however, you lose the ability to "Merge without waiting for requirements to be met (bypass rules)".

The workaround solution was to:

1. Unstack the PR to get out of the preview feature

2. Merge without waiting for requirements to be met (bypass rules)

[ajhool]

The "Bypass rules and merge" is still available on the lowest unmerged PR while stacked. So you can start on the lowest PR and work up by bypassing rules for each PR. One step easier than unstacking, but still a workaround.

[schinery]

Adding this in case it might be useful here, as we’ve hit what looks like a similar underlying issue through a slightly different path.

We’re using Aviator’s MergeQueue rather than the manual “Merge without waiting for requirements to be met (bypass rules)” button. Aviator merges stacked PRs programmatically via the GitHub App/API and is configured as a bypass actor on our ruleset for the required-reviews rule.

With the bypass mode set to “Always”, merges of non-bottom PRs in a stack were failing with:

At least 1 approving review is required by reviewers with write access.

This happened despite the Aviator App having bypass permissions, and with no manual UI interaction involved. Switching the Aviator App’s bypass mode from “Always” to “Exempt” resolved our issue.

My understanding, based on GitHub’s migration docs, is that “Always” still evaluates the rule and records a bypass event, whereas “Exempt” skips evaluation of the rule entirely for that actor.

If that understanding is correct, it seems possible that the problem is specifically related to how the required-reviews rule is being (re-)evaluated for non-bottom stack PRs when using “Always”, rather than being purely a limitation of the web UI.

It might therefore be worth checking whether the distinction between “Always” and “Exempt” also explains the missing bypass option in the web UI, or whether these are two separate issues that happen to produce a similar symptom.