GitHub Community
Repo rulesets deny me from merging PR into protected branch in usual way. #113172
Select Topic AreaRepo rules. BodyI have created personal public repo. I set ruleset, that protects my main branch. Whenever Restrict updates rule is applied I'm not able to merge pr in protected branch in usual way. I mean without with this rule enabled I see notification "Merging is blocked Is it expected behaviour? As I was expecting that all users that are in Bypass list and owner of the repository should be able to merge PR in protected branch without this warning in usual way. |
Replies: 7 comments 6 replies
|
When you set up a branch protection rule in a GitHub repository, especially one that restricts updates to the branch (like requiring status checks to pass before merging), it's designed to enforce those rules for all users, including repository owners and those with administrative permissions. The "Restrict updates" rule helps ensure that the code meets certain standards or passes specific checks before it's merged into the protected branch. However, GitHub provides an option for users with administrative privileges or those explicitly listed to bypass these branch protection rules when merging pull requests. This is likely the "Merge without waiting for requirements to be met (bypass branch protections)" checkbox you're seeing. This feature is intended as a safety valve for situations where an exception to the rule is warranted, allowing for flexibility in managing the repository while still enforcing code quality and review standards as the general rule. Seeing a warning or notification about "Merging is blocked" is expected behavior under branch protection rules, even for repository owners or those with permissions to bypass these rules. This notification serves as a reminder of the protections in place and ensures that the decision to bypass them is made consciously. The behavior you're experiencing, where you see a notification but also have the option to bypass the branch protections, aligns with GitHub's design to balance between enforcing code quality and providing flexibility in repository management. It's important to use the bypass option judiciously, as it overrides the safeguards you've put in place. If your expectation was for certain users or the repository owner to merge PRs without seeing this warning at all, GitHub's current implementation might not directly support that workflow without displaying the warning. The platform's approach aims to maintain awareness and caution whenever branch protections are being overridden. For detailed guidance or if you're looking for specific functionalities around branch protection and merging behavior that aren't currently supported, reaching out to GitHub Support or suggesting features through the GitHub Community Forum could provide more tailored assistance or lead to potential updates in future platform enhancements. |
|
Thank you for help) |
|
thank you bro |
I think it's wild that if I want to restrict pushes and merges to default branch for outside collaborators (this is an enterprise context, so contributing happens directly in the repo via branches/prs), as a maintainer (who by definition should have these rights) I have to tell GitHub that "yes I'm sure that I know what I'm doing" every single time. PRs have other protections anyway (required reviews and status checks), bypassing those should be a double confirmation. Given that it works in the expected way with the old branch protection rules, it's weird that it was implemented differently with the new rulesets. I guess I'll continue using the old functionality then... |
|
Couldn't agree more, @mihkeleidast! For us it's less about outside contributors and more about the developers being assigned to teams and the teams that know what they're doing still being restricted by requiring a by-pass for the "new and improved" way of doing things. I could even understand if the teams were set up for "PR only" and requiring a by-pass. But when they're set as "always" being able to by-pass, then the by-pass restriction is redundant and just acting as a barrier to the workflow. The desire of being able to really easily set up restrictions at the Organization level is strong, but not when it keeps hindering the workflow and requiring a by-pass to be checked. So it's back to the old way for us, too. |
|
Found this thread because I'm struggling with this too after migrating to rulesets from 'classic' branch protection. In many of our repositories we make use of the "Restrict who can push to matching branches" feature. We use this because we don't require internal (inside the company) contributors to use the fork-and-PR workflow, instead we grant them "Write" permission on the repository and rely on branch protection to ensure that they can't write to the default branch. In the new ruleset system the replacement for this is supposed to be "Restrict updates", but that rule does not allow for exemptions as the old system did. A user like me might think that putting only that rule into a ruleset and then adding the exempted users/teams to the Bypass list for the ruleset would produce the same result, but it definitely does not. Even if 'repository admins' are included in the bypass list for a ruleset which has the "Restrict update" rule enabled, they cannot merge PRs which are targeted at branches matched by the ruleset (and there is no checkbox to "bypass rules and merge anyway"). Merging PRs is literally blocked completely. This link is very relevant: https://github.com/orgs/community/discussions/150269. The help text for the bypass list is just wrong: it does not exempt the listed actors from the ruleset, even though that's what the help text says it does. |
|
To following on this, I seeing a similar message in the context of this pull-request: ImagingDataCommons/idc-index-data#9 That said, I am not able to understand why as it seems all checks seems to be passing. For context:
Notes
|
|
Moot at this point, but in case anyone comes across this it's because you've locked the main branch. That applies to PRs too. A lot of the wording around GitHub rules is really vague or terse and it makes them hard to understand. I really wish GitHub would do a better job explaining what options do. Does it apply to direct pushes only, or does it include PRs, etc. |
|
Just following on from this. I understand that PRs are being blocked when the 'Restrict Update' rule is set. I currently have local git hooks to check for commits to these protected branches but without adding users to the bypass list is there no way to stop direct pushes to branches whilst allowing PRs to be merged when they follow the correct PR process? I know force commits can be disabled but it seems insane that direct pushes can't be stopped on the github side and I have to rely on local git hooks to catch this locally. |
|
My workaround to use rulesets but enforce who can merge PRs without having to bypass rules was to create two rulesets. One ruleset includes all my intended rules including "Restrict updates" and a second ruleset that only has "Restrict updates" applied, but with repo admins added to the bypass list "Exempted from rules". Now only repo admins can merge PRs without bypassing rules as intended, but I suppose this also means repo admins are unrestricted from pushing to the target branch(s)? 🤷♂️ |
|
+1, hitting this too — and can confirm the root cause with a clean test. We have a repository ruleset (require_code_owner_review + required_approving_review_count) with a GitHub App added as a bypass_actors entry (Integration type, tried both bypass_mode: always and pull_request). The app auto-approves and calls |
|
Follow-up with concrete repro data, in case it helps someone on the GitHub side pick this up — this is fully reproducible on our end: Setup: Repository ruleset, Test A — PR with all checks green, approved by the bypass-listed App, auto-merge enabled via Test B — same PR conditions, but instead of No special override flag, no admin privileges beyond being a listed bypass actor. Result: merged instantly, no error. So the bypass grant itself is real and correctly enforced by the synchronous merge endpoint — it's specifically the async/deferred auto-merge completion path that never re-checks Workaround for anyone stuck on this: have your automation call the merge endpoint directly (Test B) instead of relying on |
|
I had the same problem, but it turns out that it was a PEBCAK. Too many rules. After simplification it works as expected. |
When you set up a branch protection rule in a GitHub repository, especially one that restricts updates to the branch (like requiring status checks to pass before merging), it's designed to enforce those rules for all users, including repository owners and those with administrative permissions. The "Restrict updates" rule helps ensure that the code meets certain standards or passes specific checks before it's merged into the protected branch.
However, GitHub provides an option for users with administrative privileges or those explicitly listed to bypass these branch protection rules when merging pull requests. This is likely the "Merge without waiting for requirements to be met (bypass bra…