[Feature Request] Allow github actions to bypass branch protection rules in certain specific circumstances

[philomory]

There are workflows in which it is desirable to have the workflow itself make changes (such as updating a pom.xml, packages.json, CHANGELOG.md, etc.) on a branch which is otherwise protected from direct changes.

Some things that don't work (or don't work well):

• Simply disabling branch protection rules entirely for the branch in question isn't a feasible solution, because there are plenty of legitimate reasons to want branch protection rules in place.
• It's not possible to add the pseudo-user represented by the GITHUB_TOKEN to the "Restrict who can push to matching branches" list, but even if it were this wouldn't be a useful solution, because then any action from any branch could bypass the branch protection rules, making them too easily circumventable.
• You can create a "service user", add that service user to the "Restrict who can push to matching branches" list, create a Personal Access Token (PAT) for that service user, store the PAT in an environment secret, assign the relevant environment to your protected branch, and then have the workflow get the PAT from the environment, and then set up extra rules in all of your workflows triggerd by push events to make sure that they ignore any commits pushed by the service user (the way they'd ignore commits pushed using GITHUB_TOKEN). This more-or-less works, but it's a lot of work to replicate this set up across dozens of repositories, and it's really abusing a bunch of unrelated functionality for something that should be available out of the box.

My proposed solution is to add a checkbox under Branch Protection rules, "Allow Github Actions workflows run from matching branches to push commits back to the same branch". Checking this box would have two effects:

1. Workflows triggered by push events to the protected branch (which, given the branch is protected, will generally represent pull-request merges rather than remote pushes) will be allowed to push additional commits back to the protected branch as if they were being pushed by an individual user who was listed under "Restrict who can push to matching branches".
2. Workflows triggered by a workflow_dispatch event, where the workflow was dispatched from the protected branch (i.e. the workflow YAML file being executed is read from the protected branch) will be allowed to push additional commits back to the protected branch as if they were being pushed by an individual who was listed under "Restrict who can push to matching branches".

Note that in both cases, the workflow should only be permitted to push commits back to the same branch that the workflow is being executed from (or other, unprotected branches, as is already possible). A workflow should not be able to push commits to any other protected branch, not even a distinct branch that matches the same branch protection rule.

This feature request is inspired by a long-running discussion in the Github Community discussion boards; I felt it was worth bringing a concrete feature request to this Feedback repository, at this point.

NOTE: If you want to show your support for this feature request, please upvote it using the upvote button

rather than replying with a "+1". Replies like that just result in sending spam to everyone else interested in the issue, and importantly, don't even "count" when it comes to how much GitHub will prioritize the issue. They're just spam, they're not spam that also counts as a vote in any way.

[xakraz]

Also mentioned and requested here: https://github.community/t/allowing-github-actions-bot-to-push-to-protected-branch/16536

[brightshine1111]

Even though it wouldn't work in all use cases for all people, treating the github-actions bot as a full-fledged app so we can add it to protected branch pushers would be immensely useful in a number of situations.

E.g. at my company the main branch is gated by PRs; once a PR is merged that triggers the deploy workflow, and part of that workflow is simply pushing fast-forward commits to a minor version branch (e.g. if the current release should be v2.3.4, deploy will update the v2.3 branch to be even with main). We want to protect these minor versions branches so humans can't accidentally push to them and get them out of sync with main. The minor branches aren't critical to any other parts of our CI/CD pipeline otherwise, so simply being able to add the github-actions bot to that branch protection rule would be perfect in our situation.

[solarmosaic-kflorence]

FYI: https://github.blog/changelog/2022-05-17-consistently-allow-github-apps-as-exceptions-to-branch-protection-rules

[timothyjlaurent]

Thank you @daniel-res 👏 👏

This is the internet's only source for this information

[b3nk3]

I was able to add the App to the bypass list under branch protection with lesser permissions than @daniel-res.

Namely:

• Action
• PR
• Contents

[DoisKoh]

When I try to Allow specified actors to bypass required pull requests, I don't see any 'apps' to choose from. How do I allow GitHub actions to bypass this?

[christian-benseler-farm]

Same for me @DoisKoh

[air3ijai]

Did you previously install required app on your repository?

• https://github.com/<usernam>e/<repository>/settings/installations
• GitHub --> Repository --> Settings --> Integrations --> GitHub Apps
• Installing your own GitHub App

We use a own app for that and bellow is an example with a public one.

screenshots

[agaertner]

Just encountered this exact issue. This is certainly great to have for smaller hobby teams as well where you don't really want nor need to setup whole delivery pipelines.
I have setup simple automatic deployment on main which commits some changes like assembly version bumps, changelog, etc. However, I have to remove the branch protection for it to function which is bad for collaborations.

[Camuvingian]

Yes, GitHub, let's get this feature in please.

[cunhap]

Would also like this implemented. 👍

[israelboudoux]

That would be a great GA to implement!

[u-ways]

+1 I had to implement a walkaround to cater for such requirements which I do not encourage following...

Update: If you're very keen, you can see multiple ideas/solutions posted across the board linking to this issue.

[andreaagudo3]

how did you do it?

[maazmmd]

Can you please post the workaround

[madhifallah]

does this fit your need ? https://github.blog/changelog/2022-08-18-bypass-branch-protections-with-a-new-permission/

[dedece35]

+1 for our open-source organization (not GitHub Entreprise :( )

[philomory]

I don't think this fits the full need even for Github Enterprise customers. This is basically somewhere between non-solution number two and number three from the original post; that custom role can't be applied to the GITHUB_TOKEN psuedo-user, you have to assign it to an actual user; if you could assign it to the GITHUB_TOKEN psuedo-user, it wouldn't solve the problem acceptably because then anyone who could push to any branch, could push a workflow that interfered with protected branches; and if you instead assign the custom role to a "service account" user and make different service account users for workflows on different branches, well, that's non-solution number three: it works, more or less, but it's way too complicated to scale.

[frankinspace]

If you have an organization (on public github); you should be able to use the solution proposed in https://github.com/orgs/community/discussions/13836#discussioncomment-2901138

That's how we solved it; we have a custom dummy "CICD" github App and our workflows that make commits back to protected branches use the CICD github app credentials when committing. Then in the repository settings we allow the CICD App to skip status checks.

I still agree though it would be better if we didn't have to create our own app and we could just allow the GITHUB_TOKEN to skip status checks directly.

[philomory]

@frankinspace Doesn't that solution still fail in that someone could e.g. push a new workflow to a non-protected branch, that workflow would run with the credentials of the app, and could therefore push to a protected branch? Essentially meaning that the protected branch is not protected?

[frankinspace]

@philomory Yes, that is still a problem. IMO that's something I can tell my developers to not do. I still agree with your feature request and consider what I described an acceptable workaround until GH can resolve it properly.

[bigman73]

Also interested in a solution - I'm trying to auto bump the version but the branch protection rule I have on main branch doesn't allow it.

[Kav-K]

Also looking for a solution! I have a python-black formatter that pushes code to the main branch but the protection rules won't allow it

[airtonix]

in your case, you should do that on your PRs: do auto formatting commits to PRs only.

[thislooksfun]

I'm running into this issue as well. I use semantic-release to automatically update my package whenever my main branch is updated, and I use @semantic-release/git to commit the updated version and changelog back to the branch. However, I also want to enable required status checks so I can have that peace-of-mind (and also use auto-merge). But I can't, because if I turn it on the action can't push the version update anymore. Having a setting (either in the branch protection rules as suggested above, or in the action itself using the new permissions setting) would be a huge help for getting my setup clean and efficient.

[satoshinotdead]

Can we bypass the permission rules with Gitbook?

We are facing the same issue but within the same company (!)

[vagenas]

As a simplification of the "service user" approach outlined by the OP: for the commit(s) pushed by the "service user", one can consider using [skip ci] to suppress status checks without adding any extra rules in the workflows (see https://docs.github.com/en/actions/managing-workflow-runs/skipping-workflow-runs).

[bigman73]

As a simplification of approach number three, one can consider using [skip ci] in the respective commit message(s) to suppress status checks without adding extra rules in the workflows (see https://docs.github.com/en/actions/managing-workflow-runs/skipping-workflow-runs).

Not sure I'm following you. The idea is to have CI workflows run, not skipped, for example to auto increment versions.

[thislooksfun]

This isn't actually about getting workflows to run or not run at all, is about being able to have workflows push directly to a push-protected branch. [skip-ci] doesn't skip branch protection rules.

[vagenas]

I am referring to the third approach outlined by the OP, i.e. enabling pushing to the protected branch by explicitly allowing a "service user" to do so in the branch protection rules and then using the "service user" via a PAT accessed through an environment secret.

My comment was that, in this context, you do not necessarily have to (copying from the OP):

[...] set up extra rules in all of your workflows triggerd by push events to make sure that they ignore any commits pushed by the service user [...]

but you could rather just use [skip-ci] in those commits instead.

[ohmantics]

[skip ci] would work for the case mentioned above of @semantic-release/git trying to push release-related changes (package.json, CHANGELOG, etc.)

[sebaacuna]

So glad I read as far as your comment @vagenas , totally solved my issue where I already had the app (service account) set up but wanted a simple way to prevent the pushes to loop. Adding [skip ci] to the commit message saved the day.

[robertleeplummerjr]

Github, this is a need for full automation after deploys. PLEASE consider this soon.

[DavidVaness]

just ran into this today...
+1

[peterdudfield]

+1

[tidusjar]

+1

[morremeyer]

Please stop Posting +1 comments. Those are ignored. Instead, upvote the initial post.

+1 comments only have one effect: They annoy everyone subscribed for actual updates.

Thank you.

[samus-aran]

I understand this perspective, perhaps we can get the OP to update their top post to ask this of users advocating for the same feature? I suspect it has been instilled in many a developer to add a 👍 to issues & PRs. It's a habit hard to break so we would need to be explicit what you or others wish is the expected behaviour 🙂

I suspect the submitting a +1 is not to be spammy intentionally but a very common way to show interest & to subscribe to the thread thus notified if there are any updates - the same way you are notified when someone comments 😉 Adding a reaction does not subscribe you to the thread so they would need to manually do this themselves if they do not post a comment.

Unless the +1 are actually spammy in nature we will currently not mark these comments as off topic.

[lobsterkatie]

Here is a discussion in which they are decidedly spammy: https://github.com/orgs/community/discussions/7923. So much so that a while back I filed this: https://github.com/orgs/community/discussions/53075.

[Oaphi]

Yes, they are spammy. It's saddening to see a reply from maintainers that those "comments" will not be removed as off-topic. Getting a constant stream of useless notifications in the inbox is bad enough, but having to scroll through countless "+1" when GitHub already has a feature for expressing support is baffling.

[philomory]

For what it's worth, I've added the requested note to the OP asking people not to post +1s and instead to upvote. I doubt it will accomplish much, but I guess it's worth a shot.

Frankly, I wouldn't count it amiss if Github just... didn't accept "+1" as a comment, and when you tried to submit a comment that just said "+1" in it, to instead display a tooltip describing more appropriate ways to express support for an issue.

[planeiii-te]

Like most resources on GitHub, commenting that you support the issue without any meaningful addition to the conversation only functions to notify people that also are unable to fix the issue in most cases.

If you'd like to show your support, react to the opening message (specifically the up arrow in this case).

If you'd like to be notified of changes (hopefully not more +1 posts), then there's a subscribe button on the right side of the page below the category and labels.

[gabricc]

Hey everyone!
After many many many attempts, I found a way to overcome this GitHub limitation.

Context:
In my company, we have ArgoCD setup and the argocd/ folder structure lives inside the application repository, so when the workflow runs, it generates a new build, a new image tag, and we have to commit that new tag to the same repository(that has branch security protections).
After I implemented this ArgoCD I had to disable the branch protections for months, but now I found a way to make it work.

Solution
I started using a self-hosted runner. With that, I have a way to control/change what happens inside the _work folder of that runner and consequently I'm able to edit what's inside _work/<repository_name>/.git/config.
Now, this self-hosted runner has a ssh private key with permissions in the corresponding repository and I added a step to change the content of the .git/config to use ssh instead of https when talking to GitHub(it uses https by default):

      - name: Update GIT Config
        working-directory: .git
        run: |
          sed -i "s|url = https://github.com/<org_name>/<repo_name>|url = git@github.com:<org_name>/<repo_name>.git|g" ./config

I know this is a pretty hacky solution, but with that I was able to re-enable branch security protections:

I hope it helps!

[angelarosario]

Thanks for sharing!

Is it possible that the reason this works is not more so because you started using ssh but because it happens that the github user (associated with the ssh key) configured in the self-hosted runner has a role that can bypass branch protections (e.g., an admin)?

If so, this strategy resembles the third option provided by the original post, except that this uses an ssh key instead of PAT.

• You can create a "service user", add that service user to the "Restrict who can push to matching branches" list...

[gabricc]

that's correct, the github user associated with that ssh key is admin in the repository and for this reason it is allowed to bypass the branch protections.
Hmm, my understanding of this "Restrict who can push to matching branches", is that we specify people allowed to push to that repo regardless of the branch security rules previously defined:

Specify people, teams, or apps allowed to push to matching branches. Required status checks will still prevent these people, teams, and apps from merging if the checks fail.

I also did some tests using a service user, none of them worked, even after adding the user to the Allow specified actors to bypass required pull requests list. But, I might've missed something.

[sfc-gh-smisra]

Now you can use a GitHub App to bypass certain controls in branch protection rules or newly introduced Repository Ruleset depending on your requirement.

- name: Commit and push changes run: | if [[ -n $(git status -s) ]]; then git config --local user.email "github-app[bot]@users.noreply.github.com" git config --local user.name "GitHub App[bot]" git add . git commit -m "Updated file" git push --force else echo "No changes to commit" fi env: GITHUB_TOKEN: ${{ env.MY_GITHUB_TOKEN }}

 In another file where I generate an installation access token from a GitHub app private key, I store the access token in runner environment variable. 
 
 And in the repository ruleset, I configure this app to bypass required branch protection setting.

[Kiyo5hi]

I have tried the above but it is not working for me; it still gives me error that PR is required. I wonder are you using ruleset or branch in repo settings to protect your branch? Also, what perms you have assigned to your GitHub App?

[sfc-gh-smisra]

I am using repository ruleset feature, instead of branch protection rules in repository settings. You have to provide the bypass actor "Always" permission if you want to directly push to the repo, or "for pull requests only" permission if you want it to create a PR , but merge that automatically.

[Kiyo5hi]

I have configured that correctly. It seems like you are on "Evaluate" status instead of "Active"? I think "Evaluate" mode does not enforce the rules, or does it?

[picturedesk]

We had the same issue and we were not able to push because at least 3 checks are required. Our problem was, that we run the git pushcommand like this:

  - name: Commit version bump
    run: |
      git push
    env:
      GITHUB_TOKEN: ${{ secrets.READ_WRITE_PAT }}

Now we are using a dedicated github action to push with a particular PAT. We are using ad-m/github-push-action

  - uses: actions/checkout@v4
    with:
      ref: ${{ github.head_ref }}
      persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal access token.
      fetch-depth: 0 # otherwise, there would be errors pushing refs to the destination repository.
      token: ${{ secrets.READ_WRITE_PAT }}

..

  - name: Push changes
    uses: ad-m/github-push-action@master
    with:
      github_token: ${{ secrets.READ_WRITE_PAT }}
      force_with_lease: true

[ramanpreetSinghKhinda]

+1

[iamfj]

+1

[suizman]

+1

[willcipriano]

Need this

[treyenelson]

I was able to work around this deficiency by using the Github App approach discussed above. I had never created an app before, so here is the list of steps that were necessary for anyone looking for something a bit more comprehensive:

• Follow the official guide to register an app and add the app id and private key to your repository's variables and secrets respectively: Making authenticated API requests with a GitHub App in a GitHub Actions workflow
• Configure your app with the following in the Permissions & events section (courtesy of @daniel-res)
  • Actions (read/write)
  • Administration (read/write)
  • Contents (read/write)
• Update your ruleset bypass list to include your Github App
• Obtain and use the app's token in your workflow. This is an abbreviated version of what I use for auto-incrementing my version number:

jobs:
  commit-version:
    steps:
    - uses: actions/create-github-app-token@v1
      id: app-token
      with:
        app-id: ${{ vars.YOUR_GITHUB_APP_ID }}
        private-key: ${{ secrets.YOUR_GITHUB_APP_PRIVATE_KEY }}
    - uses: actions/checkout@v4
      with:
        token: ${{ steps.app-token.outputs.token }}
    - id: increment-version
      run: |
        # ... run a script that increments the version
        #
        echo "VERSION=$(cat ./package.json | jq -r '.version')" >> $GITHUB_OUTPUT
    - uses: EndBug/add-and-commit@v9
      with:
        message: "Increment version to ${{ steps.increment-version.outputs.VERSION }} [skip ci]"

Note that this approach is not particularly secure and could be used to bypass the ruleset to commit arbitrary code by someone that has the ability to modify a workflow and trigger it in your repository.

[marengaz]

thanks for the instructions, have successfully followed them!

note: the following permissions are not necessary for the app to have, to successfully complete the above workflow:

• Actions (read/write)
• Administration (read/write)

[asos-danielc]

I just tested this but needed these 2 permissions still... could it be you do not have any checks specified in Require branches to be up to date before merging? I know when I didnt have any selected then it was fine, but when I added checks, it started failing, and adding the Administration permissions fixed it again.

It doesn't feel ideal at all, but it worked

[HiromiShikata]

@asos-danielc
Thank you very much!
It's very helpful for me and it works right now 🙇

For folks
I took much time because Do not allow bypassing the above settings on branch protection was enabled.
We need to disable Do not allow bypassing the above settings, please take care 🙏

[pkozuchowski]

I'm not sure I understand. GitHub does not want to resolve this, because anyone would be able to deploy to protected branch by creating a workflow file (comment here @chrispat)

If I create a workaround with GitHub App or personal access token, what's stoping people from creating new workflow file and using my app/PAT to deploy maliciously to protected branches? The problem is still there, just a bit more limited.

I think it would be much safer, if there was a setting to allow only repository administrators to push any changes in .github folder. Then you wouldn't have to worry about malicious actors abusing workflows and the workflow bot could have more privileges.

[j616]

There are ways you can mitigate against this. Enable review of all 3rd party run requests. Or require an environment that requires review or locks to protected branches.

You could, of course, use a write-enabled deploy key and a Ruleset bypass. I believe in this case, that would act as a repo admin-level key. I believe this would behave in the way you are suggesting. But then you need to allow ALL admins to push to the branch in question. You cannot select deploy keys in repo Ruleset bypass settings. And bypass lists seem to be most-permissive, not least. So you can't do a combo of allowing Admin Always, and a team of human accounts For Pull Request Only to prevent the humans for pushing direct to the branch.

[adam-eichelkrautctpg]

For folks that wish to go down the service account PAT route, I found this helpful for authenticating our git command line:

  steps:
    - name: Checkout
        uses: actions/checkout@v4
        with:
          token: ${{ secrets.YOUR_SECRET_TOKEN }}

The token configuration also configures your local git credentials, see https://github.com/actions/checkout