Can we have "Allow specified actors to bypass required status checks" settings?

[Colin-b]

Select Topic Area

Question

Body

As of right now, using GitHub Enterprise, I can put, under the required pull requests, the following settings:

• Allow specified actors to bypass required pull requests

This allows me to have some account that can push to a protected branch without using a pull request (for some automated flow, typically auto-versioning, but it could be anything else really).

The problem is that, if you put required status checks, the push will fail, as it's a direct push to the protected branch (so there is no status).
In order to keep consistency, I think the following setting should be introduced for status checks, the same way it already exists for pull requests:

• Allow specified actors to bypass required status checks

This will allow to put status checks as required, such as status that are pull requests specific (only triggered when a pull request is opened, synchronized or reopened). Because right now there is no way to mark those status as required while having someone bypassing pull requests.

Thanks again

[justinmchase]

I came here to ask this exact same question for the same reason; I am attempting to build automation around versioning.

I am using the release-drafter action, which will produce a Draft Release as users are merging their PR's and it formulates a new version based on the labels of the accumulated PR's. I have made a Github App which responds to release.draft events and will make a commit based on the label of the release. That way when the user publishes the release, the Tag that is created is for a commit which already has that version applied in code.

My code, as is very common across many different application languages and runtimes, requires the version to be located somewhere in the code (or multiple places). If I'm automating the process of incrementing versions I need a way to apply that version to the code in an automated way. Being unable to push into main branch without granting excessive admin permissions is very prohibitive.

That's my scenario but I think its safe to say that regardless of my workflow here there exists legitimate scenarios where automation should be able to push commits directly to protected branches without review. These commits should not require admin privileges though it seems reasonable to require that these users / apps / teams be granted that permission specifically.

If that above statement is true then I 2nd @Colin-b's comments and proposed solution; an "Allow specified actors to bypass required status checks" is a perfect solution.

[justinmchase]

Another way to phrase this is that it seems like if you cannot commit without the status checks then there is no point it allowing a user to bypass pull requests because there seems to be no way to actually run the checks against a commit without a pull request (since actions typically only trigger on pull_request events).

And after some experimentation, if your user who can bypass pull requests does create a Pull Request to trigger the status checks, then they still cannot merge the PR if you have other requirements (such as approval related requirements).

So it seems like the bypass pull requests feature does absolutely nothing if you cannot also bypass status checks.

[justinmchase]

I was able to actually bypass the other checks by using the --admin flag with the gh cli. The user isn't actually an admin but because they can commit without a PR it seems to work.

Therefore the workaround is to create a PR, listen for check_suite events and then once completed attempt to merge the pr with --admin flag.

[Colin-b]

There is a bunch of workaround yes, however, except for the one disabling the status checks pre-push and reactivating them after the push, none is "instant", meaning they all introduce a delay in actually doing the push in the target branch of the modified files.

In my use case I need it to be as fast as possible and relying on actions is not an option as you might be waiting for a runner.

[justinmchase]

Also doing it in an action is potentially problematic since, anyone can make a PR with adjustments to that action which could allow it to make commits you don't want to allow.

In my case I made a github app, which has to go through its own code review process and has a user tied to it which has to have the specific permissions.

But yes I agree still, that app still can't commit with these status checks in place without creating a whole PR and auto merging it after the statuses are run, which has a delay and can run into extra problems.

[justinmchase]

Would it make sense to just have the "Allow specified actors to bypass pull requests" to just also always be allowed to bypass status checks? It seems pointless to be able to bypass PR's without being able to also be able to bypass status checks.

[travi]

But my status checks are triggered by PR specifically, so how can I run that check against a commit without the corresponding pull_request event?

checks that are set as a result of a pull_request trigger would never be triggered without a PR, you are correct. my point is that not all projects have required checks that are the result of pull_request triggers. checks that result from push triggers, for example, can be satisfied without a PR.

[Colin-b]

For information, status checks are not workflow specific, so you can have the same status check from the one on your PR related triggers but triggered upon push (and doing nothing let's say, so that you have instant success upon job run).

However this, of course, introduce unnecessary complexity in your actions and still requires to wait for a runner. Also it would require the following flow: push to another non protected branch -> trigger all the required status checks with success -> merge this branch within your protected branch without a PR.

[justinmchase]

I see, I didn't realize you could trigger it off of a push specifically. Right now what I'm doing in my App when I need to commit to main, is to create a branch, push the changes there, then create a PR. That then triggers all push and pr events. After each check_suite complete event is sent to my app successfully I try to merge the branch, eventually it will work as all the required status_checks complete.

one example i have for this is with renovate.

@travi Can you elaborate? I'm not sure what that is.

So in your scenario where you are granting specific users the ability to push to a branch, but they must run status checks off of the "push" events and then merge to main without a PR, is it safe to say these are people and not automated processes? And if so why is it ok for them to do this? In my company this would violate our audibility requirements.

I could also envision a situation where you want to require the PR for audit trail purposes but you want to allow certain users to bypass the checks if they need to merge...

It does seem like there is a distinction between Human users and Automation users, which is probably hard to infer completely.

So considering that, a second option for adding users who can bypass status checks for the branch sounds like the best way to be flexible to any scenario, while being still pretty easy to understand. The one setting up the branch protections would know that the user they are specifically granting bypasses too is human or a robot and their intent best.

[travi]

It seems pointless to be able to bypass PR's without being able to also be able to bypass status checks.

@justinmchase the information that i've added to this thread is in response to this suggestion. i'm just trying to highlight that there are valid use cases where the lists would need to be different, so it isnt reasonable to expect defining a single list to handle all of these cases.

i'm not suggesting that this applies to your use case and i dont know enough about your context to suggest what would work for you. i dont think solving for your use case is useful here.

[justinmchase]

Yeah thats fair, I think I'm agreeing with you, just walking through the logic.

[cloph]

same: #18145

[Colin-b]

Indeed, however the category might be misleading. Do GH developers even check this and can we hope for an answer? I see that this thread is already half a year old.

[Macmee]

Hey, I think this is broken. When trying to specify a team for "Allow specified actors to bypass required pull requests" the autocomplete selector will now surface teams, only users.

[justinmchase]

I'm now realizing that if you have a CODEOWNER specified, then you can't even merge the PR automatically without a PR review regardless of any settings.

[bahag-gugelm]

Still an issue. Signing under all above.

[gmocquet]

Same issue here

[bahag-gugelm]

A way to circumvent the branch protection rules and to be able to commit and push the version bump and the changelog from an action back to the code, could be using an SSH key pair added to the repo, the public part as a deploy key (with r/w permissions) and both private/public ones as the repository secrets. In order to work correctly, one has also perform checkout using the supplied key. For publishing to the GH release, the default runner token (GITHUB_TOKEN) is sufficient. Also, don't forget to pass those secrets to the job with a parameter secrets: inherit while calling it from the parent workflow.

release.yaml example

 
on:
  workflow_call:
 
env:
  GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  SSH_PUBLIC_KEY: ${{ secrets.SSH_PUBLIC_KEY }}
  SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
  GIT_COMMITTER_NAME: semantic-release
  GIT_COMMITTER_EMAIL: [email protected]
 
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-python@v4
        with:
          python-version: 3.9
      - name: Git & SSH auth setup
        run: |
          # See https://github.com/actions/runner-images/issues/6775#issuecomment-1409268124
          # and https://github.com/actions/runner-images/issues/6775#issuecomment-1410270956
          sudo git config --system --add safe.directory "*"
          if [[  -n $SSH_PUBLIC_KEY && -n $SSH_PRIVATE_KEY ]]; then
              echo "SSH Key pair found, configuring signing..."
              mkdir ~/.ssh
              echo -e "$SSH_PRIVATE_KEY" >> ~/.ssh/signing_key
              cat ~/.ssh/signing_key
              echo -e "$SSH_PUBLIC_KEY" >> ~/.ssh/signing_key.pub
              cat ~/.ssh/signing_key.pub
              chmod 600 ~/.ssh/signing_key && chmod 600 ~/.ssh/signing_key.pub
              eval "$(ssh-agent)"
              ssh-add ~/.ssh/signing_key
              git config --global gpg.format ssh
              git config --global user.signingKey ~/.ssh/signing_key
              git config --global commit.gpgsign true
              git config --global user.email $GIT_COMMITTER_EMAIL
              git config --global user.name $GIT_COMMITTER_NAME
              touch ~/.ssh/allowed_signers
              echo "$GIT_COMMITTER_EMAIL $SSH_PUBLIC_KEY" > ~/.ssh/allowed_signers
              git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers
          fi
      - name: Checkout code
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ssh-key: ${{ env.SSH_PRIVATE_KEY }}
      - name: Semantic Release
        run: |
          pip install python-semantic-release
          semantic-release publish -D commit_author="$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>"

[justinmchase]

Can this work for apps? What if you're installed on a ton of repos?

Can any workflow, in any branch now make any commit now? Or does this just commit into an unprotected branch?

[bahag-gugelm]

This is just a way to commit from an action to any protected branch that I finally came up with. Sure, it's an individual repo solution, and it doesn't require any github app to impersonate it as an actor to be added to the branch protection bypass whitelist.

[wheelerlaw]

This is what GitHub needs to implement:

[torressam333]

I added a CI User as an admin to my repo and I can't find their individual user in my ruleset bypass list.

[torressam333]

@patrick-knight

[patrick-knight]

Creating a team or role for that actor would be the way to handle that, as we don't list named users directly in the bypass lists.

[torressam333]

Makes sense. If I layer a ruleset to allow the CI user to merge into my dev branch, will that work in conjunction with my existing dev branch protection rules? Which one of the two takes precedence?

[patrick-knight]

They layering works to ensure all protections from rules and branch protections must be true. If an actor has conflicting bypasses across rules and branch protections, that actor would not bypass as both have to be true to allow the bypass.

Here are the details in the docs about that behavior

[na-jakobs]

Much needed feature 🙏

[tuomaskujala]

+1 for this!

[svanherk]

I was very optimistic this was solved by the new Rulesets functionality, but it doesn't appear to work for our use case (using a GitHub app token).

[justinmchase]

It seems like it is intended to be the solution for this and there are simply some errors. Keep checking in with it as it progresses to be out-of-beta status.

[patrick-knight]

Apps should be working now for all bypass scenarios.

[ravi-vunet]

+1 for this

[patrick-knight]

Y'all should check out Repository rules for this use case.

Rulesets support layering, meaning you can set a craft a set of rulesets that have bypass targets on apps, roles or teams. You can configure rules in such a way you can enforce status checks for all, but allow the bots or teams to merge bypass those requirements.

In this case you’d create two rulesets in your repo.

Required for some

• Bypass list:
• Target branches: default branch
• Branch Protections:
• Enable: “Require status checks to pass before merging” and “Require branches to be up to date before merging”

Required for all

• Bypass list: empty
• Target branches: default branch
• Branch Protections:
• Enable: “Restrict Deletions”
• Enable: “Block force pushes”

Theres a discussion for rules over here

[justinmchase]

So are the rules not a logical AND?

[wheelerlaw]

They are more similar to "bitwise" OR.

[MikeDabrowski-EQM]

Close but we are unable to add github-actions user to bypass list

[jdbruijn]

Just tried it yesterday as well, after the June 27, 2023 updates on the rules. Works great now with empty branch protection rule on main to prevent deletion and force pushes and then rules on main to require status checks before merging, allowing app to bypass 😄

[jayshah123]

Quite a useful feature for version bump and other use cases.

[nnellanspdl]

Really need something like this. It's blocking my automation attempts.

[mkienenb]

switching from "branch" rule protection to "ruleset" protections let my Github App bot bypass required status checks, so that's definitely the way to go.

[torressam333]

How?

[patrick-knight]

Here's the docs for rulesets and a screenshot of what the bypass list offers with a few examples.

[alper]

What does this setting even do?

"Allow specified actors to bypass required pull requests"

The brach protection rules are a total mess and it's nearly impossible to figure out what any one setting there does.

I need certain people to be able to merge PRs without waiting for checks or reviews. Not sure if this fits the bill there.

[ViliusS]

I agree, protection rules are complex to understand, but they are flexible and very powerful.

"Allow specified actors to bypass required pull requests" doesn't exist anymore in protection rules. What you must do instead is configure Bypass List for protection rules which you want your users to be able to skip. Bypass List can be applied in every context (for example direct commit rule to the branch), or in PR only context (for example review requirement rule).

So to answer your question directly. You should split your rules into the ones you want certain people to skip and the ones applied to everybody. Then add those certain people to checks/review rule under Bypass List with "For pull request only". For example:

1. Rule A for master branch - Block Force Pushes [x], Restrict Deletion [x]. Bypass List is empty.
2. Rule B for master branch - Require PR before mergin [x, at least 1 approval], Require Status Checks to Pass [x], Bypass List [YourCertainGroup - For PR Only].

These two rules will deny direct commits, force pushes and deletion operations on master branch and will require everybody to do PR, but CertainGroup will be allowed to skip approval and status checks on those PRs.

Personally I suggest that every rule implements one organizational policy. Policy examples:

1. Files larger than 2 MB require LFS.
2. Tags are never created manually.
3. Any modification of tags (force pushes, deletion, etc) are not allowed.
4. Force pushes and deletion of main development branches are prohibited.
5. Only CI bots can can merge into master.
6. Developers must always merge into develop.
   etc.

This way you will have a) structure, b) can decide who can skip policies, and who don't.

[alper]

This means we've been forcibly moved to Rulesets (which we now have to configure) without notification?

[ViliusS]

I don't understand what you mean. You can use either Rulesets, or Branch Protection, or both.

[wheelerlaw]

Branch protection settings have always lacked the ability to allowlist certain users from being required to pass status checks (unless you have them configured as repo admins and made sure that the branch protection settings are not being enforced for repo admins). But it does look like GitHub has removed the ability to allowlist certain users from being required to open a PR.

In either case, the only way to let a user bypass status checks is to use rulesets (this has always been the case).