The 'exempt' bypass status in a ruleset isn't recognised.

[kapios010]

The problem

When I set the bypass type in a ruleset with restrict updates selected to exempt, the desktop app blocks me from pushing to the repo, even though I can do it just fine with another client, for example the VSCode integration. When the bypass status is changed to always allow, it lets me push just fine, the same happens when said ruleset is disabled.

Release version

Version 3.5.4-beta3 (x64)

Operating system

Windows 11

Steps to reproduce the behavior

No response

Log files

No response

Screenshots

When set to always allow:

When set to exempt:

Additional context

No response

[ofek]

This is actually a broader issue that I encountered this morning where it doesn't recognize the bypass mode. When enabling the Require a pull request before merging rule and adding yourself to the bypass list specifically for pull requests (i.e. can't push directly but can bypass PR sub-rules) the message indicates the ability to bypass without the ability to commit. When committing from the CLI and trying to push, you can see that the ruleset is actually in effect. In this situation, the commit restriction is the correct behavior and only the associated message is incorrect.

[PrestonTaylor]

In my case it doesn't even present an error, the button is simply disabled with no recourse and no message (maybe an artifact of GHE?). Committing from CLI works perfectly fine with an added "Bypassed rule violations" message in output. If I set my exclusion to be for "For pull requests only" the button is enabled again (after restarting gh desktop) so it's applying intelligence to the exclusions just not the most basic one, "Exempt".

Why does this validation exist on the client side at all??? The client should simply push and wait for the response. Any attempt to add another layer of validation of rules here is going to be very complex and difficult or impossible to reconcile to always have exactly the same result as the server side especially as server side feature creep keeps taking place there for the sake of automation etc.

[niik]

Hey @PrestonTaylor, @ofek Thanks for reporting this. It seems that exemption rules shipped quite a while after we shipped our initial repo rules support so chances are this got missed. I've tagged this as a bug and put it up on our board for the team to discuss.

[ofek]

Thanks a lot! I see this is now labeled as priority-2; what are the various priority levels and their meaning?

[niik]

@ofek You can hover over the labels for a brief description. For priority-2 it's Bug that affects more than a few users in a meaningful way but doesn't prevent core functions. It's quite arbitrary but the reason I chose priority-2 here is because of the relatively low number of users this affects.

[mourner]

Just wanted to add that I'm also affected by this and it severely impacts my work to the point that I have to use alternative git clients (even though I love GitHub Desktop). 😭 I'm maintaining a lot of popular open source projects, and those that are under my employer's organization have branch protections set up, but I'm exempt as the primary maintainer of those repos, hence the issue — GitHub Desktop doesn't allow me to commit to main.

[mourner]

@niik I made a PR with a fix (it's pretty small and simple) in #22460, but the bot is telling me it'll be closed if this issue doesn't get a help wanted label. Can you add it, and possibly take a look at the PR too? Thank you 🙏

[ofek]

@sergiou87 @tidy-dev Hey there! Would one of you be able to add the label?