Allowing github-actions[bot] to push to protected branch

[robozevel]

Hello,

I’m using Github Actions to auto approve and merge pull requests. I wasn’t able to allow github-actions[bot] to push to a protected branch using the settings page though, so I ended up using the REST API instead.

Would it be possible to allow this using the settings page? or enable it by default?

protected-branch.png1430×676 68.2 KB

Thanks!

[chrispat]

If we enabled GitHub Actions to push to a protected branch then any collaborator in your repo could push any code to any branch they wanted simply by creating a branch and coding the workflow to push to to some other branch.  Using the REST api to merge the PR is the right flow and overtime hopefully there will be actions that make that easier to implement.  

[ajoiner-fnba]

The problem with building some automated pull request workflow is that when I push to a branch using GitHub actions, subsequent GitHub actions don't run. If I push to the branch by generating a pull request and then auto-merging that pull request, subsequent GitHub actions will run, and now I have to manually build something to discern between the auto-generated pull request being merged and any other pull request.

I think this is a cut and dry example of a feature that's missing. Please don't come up with excuses like 'security' just because you don't feel like implementing the feature. The feature could very easily be built in a secure way, so that's not an excuse.

[GitMurf]

For anyone else looking for the "true" accepted answer, this is what worked for us: https://github.com/orgs/community/discussions/25305#discussioncomment-8256560

[GitMurf]

@chrispat is there any way you could consider updating the accepted answer to something like the one I linked to? Thanks!

[jason-berk-k1x]

Using the REST api to merge the PR is the right flow

Can someone explain how this would work?

[FlorianCassayre]

I think that @chrispat did not properly understand the use case here. The comments above provide some good arguments why this feature is needed.

[robozevel]

Thanks!

Do you know of any possible solution to allow auto-merging as part of a workflow? I think it’s a common issue.

I’ve looked into automerge-action and it seems to suffer the same issue, the docs suggests using a pesonal access token but from my understaing it’s just as vulnerable.

Could there be any way of maybe limiting GitHub Actions to merge/push to the branch that invoked the workflow? or scoping secrets by branch? or auto-merge outside of GitHub Actions once all check runs are done?

[merlinnot]

I found a partial solution to this, it allows you to have protected branches that require 1 approval and a green CI. See https://github.com/ridedott/dependabot-auto-merge-action.

[bradleat]

The same thing applies for other bots. I don’t understand why you don’t allow the CodeOwner feature to prevent updating workflows, and then allow the github action bot to push to the same branch that triggered it.

Right now practically I have to choose between protecting branches and using Github Actions on that branch.

[mtesch-um]

This is kind of not a solution to the problem, it’s not necessarily true that any collaborator could do what you say, why should the workflow have the same permissions as an Action?  The collaborator would also have to be able to control the specific Action and what it does, not the whole runner.  Consider the following extremely common scenario:

• master is a protected branch, pushable by only administrators

• master furthermore has “require review” enabled

• feature branches are submitted as PRs

• when a PR is accepted, it gets pushed to master

• when a PR is pushed to master we want an auto patch version bump and tag of that version, on master

If a malicious collaborator wanted to run arbitrary code through a commit, they would have to get this arbitrary code through the review process.  It seems a bit paranoid to not create this feature based on the argument that a reviewer might make a stupid mistake, that is true regardless of whether the feature exists or not.

What we need to make this last step above work is for Actions to have their own permission set (or a way to make an imported action get the permissions of an App?  Or an App to work like an action?)  With a small modification to @robozevel 's suggestion, it seems like a good solution.  If there’s a way to do that already, I haven’t been able to find it, but would be more than happy to hear it!

[itsalaidbacklife]

This is exactly the workflow I am trying to support as well. Only organization members can review and merge the PR, but then I want the version bump to be committed automatically. I would highly value official support for it

[Crymzix]

I agree with this. @chrispat 's answer completely overlooks this common workflow and it would be great if there was a way to allow this to happen by allowing the GitHub token to have more fine-grained permissions.

[hipstersmoothie]

@chrispat I have created a token with every scope and I still can’t publish from a GitHub action. Everything works fine locally using this token. What could possibly be going wrong?

[tripodsan]

hi… did you figure out why this happens? I have the same issue.

[tripodsan]

btw, I found a solution by reading the documentation of:

GitHub

cycjimmy/semantic-release-action

GitHub Action for Semantic Release. Contribute to cycjimmy/semantic-release-action development by creating an account on GitHub.

it is important to either set the persist-credentials: false for the checkout action, or to use your own token for the checkout action.

[joaomariocosta]

@itsalaidbacklife i tried the same but still get the same error. is something else needed?

[seriouslysean]

@ghcsimon2 I put together an example repo with workflows that @itsalaidbacklife and I use on Cuttle. Hope it helps!

[kevcube]

Yes thank you @tripodsan, this is exactly what I needed!

[craigbroadman]

@seriouslysean / @kevcube - from what I understand, you are using a Personal Access Token {{ secrets.PAT }} that allows the package.json file to be updated from a GitHub action and it bypasses the branch protection rules. Is that correct? If so, what scopes were enabled for the Personal Access Token to ensure that it wasn't just completely open to be able to do everything?

[seriouslysean]

@craigbroadman all it needs in the case I wrote about is to read meta data and read and write code.

[robtayl0r]

Personal Access Tokens are an anti-pattern here. When that user moves teams or leaves the company the actions will begin to fail.

The concept of a service account/user is the subject at hand here and it is not a new concept. The GITHUB_TOKEN used by Actions (a [THE] service) is how it authenticates with the repository service.Any traditional CI platform would allow you to assign specific roles and permissions to (one or many) service account as you would any user.

The fact that Github doesn’t allow this is a short coming. If you are inclined to create an entire Github user, inviting it to your team, this may work, but is not an ideal solution. Aside from the extra $4/mo cost to have this (service) user, a downside is you are now adding to your attack surface area for security breaches. Lock that user down with MFA? Great, now who owns the one time password/mfa registration? You are left in the same spot the PAT problem up top.

tldr; It’s absurd that the Github repository settings will not allow you to define how you want to trust it’s own internal service’s (Github Actions) token.

[ajoiner-fnba]

While I agree that the current 'answer' is terrible and we shouldn't have to resort to PATs linked to 'fake' users, one thing we've done is buy a hardware TOTP MFA fob and put that in a managed lockbox we have. If you want to get the MFA fob, you have to sign in and check it out.

That in and of itself sounds absurd, and I agree creating 'fake' users to act as service accounts shouldn't be something GitHub forces you to do, but if you are painted into that corner that's an option.

[icopp]

Is there still no option here that doesn’t require the anti-pattern of creating a bot user just to work around Github limitations?

[crazy-matt]

@chrispat Could you please explain us what could go wrong with the workflow described by @mtesch-um, I sum-up: PR reviews enforced including for administrators?
You throw up your answer but avoid answering to someone who got a real point here. What do we do to use Github with reviews including for administrators + automation?
As the others, I’m genuinely asking because we have a real use case that is explained and you don’t explain your view actually.

[itsalaidbacklife]

I think the issue is that if the actions are allowed to modify protected branches then anyone with write access to the repository can create a branch that modifies the workflow file to push to that protected branch (or other protected branches) under arbitrary circumstances e.g. “when I push to my new unprotected branch, commit whatever I like to main and push”.

It essentially granted everyone with write access the administrative privilege of overriding branch protection

[ghcsimon2]

@itsalaidbacklife
So, don't apply this automatically to the workflow files but others. This can be done easily by filtering for .github directory as an exception.

[jorhett]

@chrispat Now that this feature has merged, all we need is that GitHub Actions job runner could be selected for this Allow bypassing required pull requests | GitHub Changelog

This can be secure if you always run the master branch version of the jobs, and you have CodeOwners on the .github/workflows/ directory.

[chrispat]

This still wouldn’t be secure as the GitHub Actions user isn’t branch specific. So adding it to this list would mean that anyone could push from any branch using a workflow and bypass all branch protection rules.

In fact we are currently rolling out a change to prevent the GitHub Actions user from being included as a valid code reviewer for the required reviewers rule.

At the moment I can’t think of any mechanism that could safely enable force pushing to a protected branch using code that is inside the repo.

[Hronom]

Can we then find someone else who can develop solution for us?

For example check if we building right now in github action that was triggered by changes from the same branch?
If actions/checkout@v3 step pulled main branch then there added extra token(GITHUB_PROTECTED_BRANCH_TOKEN) that will allow to push in only main branch.

Or something like this?

Here this also mentioned https://github.com/orgs/community/discussions/25305#discussioncomment-3247415

[austinsasko]

Well at present, users are inserting personal access tokens to do what the GITHUB_TOKEN secret should. Even making it so that ONLY on the main branch the token can override protected branches would be a huge step forward.

[Hronom]

cc @chrispat

[ringerc]

This is still a problem.

What I think the people in this thread want is a way to say "prevent inadvertent pushes to branches by repo owners, but make it possible to override that protection deliberately".

Github doesn't give repo owners a way to act with lowered privileges day-to-day via the web ui. For the API and git server there are (very limited) facilities in place via PATs, but even the new 'fine grained' PATs don't actually allow much control over rights. AFAICS you cannot create a new 'fine grained' PAT as a repo owner that denies the "push to protected branches" right. So you have to keep on enforcing protected branches for admins. Which brings us full circle back to this problem.

What I want is a way to interact with the UI, API and git server in a way that "drops" my owner/admin privileges. So unless I explicitly and deliberately elevate my privileges, I am subject to branch protection rules etc, whether "I" am acting via a web session, github action using my PAT, or anything else. Essentially I want to be able to un-check some of the PAT permissions for my default web session.

Then I want to be able to create a PAT that acts with greater privileges than my default privileges - e.g. a "can override branch protection" permission. So I can delegate that right explicitly only where I actually intend it to be in force.

(With that said, I think the vast majority of workflows that rely on pushing new commits to protected branches are abuse of the workflow system. They should generally be replaced with workflows that act on branches before they are merged, so they can be approved by all mandatory checks and then undergo the normal merge workflow.)

[ringerc]

A colleague I discussed this with noticed the feature shown in this screenshot:

“Allow specified actors to bypass required pull requests”

See https://github.blog/changelog/2021-11-19-allow-bypassing-required-pull-requests/

That will help a lot for people who want CI bots to be able to merge to otherwise-protected branches, assuming it works how it sounds like it should.

Be extremely careful if you use this: Your CI bot should push a specific commit hash to prevent nasty races if you have less-trusted people who have the ability to push to non-protected branches. Otherwise they can push new commits onto the branch the bot is about to merge between when the bot checks it and when the bot pushes it.

[dataviruset]

“Allow specified actors to bypass required pull requests”

See https://github.blog/changelog/2021-11-19-allow-bypassing-required-pull-requests/

That will help a lot for people who want CI bots to be able to merge to otherwise-protected branches, assuming it works how it sounds like it should.

The problem is that this only allows specific GitHub accounts to bypass the rules (authenticated via a Personal Access Token (PAT)), but not if you're using the native GitHub Actions workflow permissions (GitHub Actions bot) with GITHUB_TOKEN.

[bradymholt]

I don't see this as an option when creating a new branch protection rule. Perhaps it has been removed?

[anshitbansal21]

I think this option is for enterprise only

[ViktorDronov]

in any case this does not work for bots which work with GITHUB_TOKEN

[shakefu]

Our case is pretty straightforward and this has been quite a problem:

• Merge a PR to main branch
• Release workflow kicks off
• Within the Release workflow we generate a new Semantic Version number
• We want this version number to be updated in the codebase (e.g. package.json, pyproject.toml) and on the same commit SHA that the Release will be cut from
• We update the file in the runner workspace
• We commit that file with a non-release SemVer conventional commit (e.g. "chore: release 1.1.1")
• We push to the main branch to keep the repository sync'd with the new target SHA which includes the bumped release
• We use Semantic Release to create a new Release object, changelog, and Tag

The problem we have encountered is:

• We cannot use the default secrets.GITHUB_TOKEN
• We have to give elevated permissions to a PAT to push to the main branch, bypassing Branch Protections
• Using a PAT to make that push means that we kick off all the same main branch Workflows again (wasteful, at best - this does not create a new release, since we are using a Conventional Commit chore:, but the flow still runs)

Many projects seem to just settle for bumping the in-code version with a PR after the Semantic Release, however the end result is that when you view the released tag (e.g. "v1.1.1") the code at that SHA will not have the correct version (e.g. ("v1.1.0")) because the PR could not be merged first.

Any solution that isn't absolutely bonkers (e.g. using intermediate branches, workflow dispatches, etc.) would be great, since even GH/GHA itself uses SemVer and suffers from this in a few of its repositories.

[dataviruset]

In our company we coded the version bumping workflow ourselves so we can use a GitHub App instead and we bump the version to prepare for further development (after our build/release flow has run). That way, the version in package.json during feature development will be the version that gets released. The commit SHA will be correct. Every version bump commit has [no ci] on the second line so it won't trigger a new workflow run and it will be hidden in the commit log on GitHub's web interface. More info about that in the docs.

The workflows need an extra step to generate a token from the GitHub App ID and private key before it can be used. tibdex/github-app-token can be used for this.

The app needs to have read and write Administration access to override branch protection rules such as requiring pull requests and status checks to pass. If you only need to be able to bypass the pull request requirement, the GitHub App can be added to the exception list in the branch protection settings of your repository, but in our case we also needed to bypass the status check requirement and there's no exception list for that (yet).

[timothyjlaurent]

The app needs to have read and write Administration access to override branch protection rules such as requiring pull requests and status checks to pass. If you only need to be able to bypass the pull request requirement, the GitHub App can be added to the exception list in the branch protection settings of your repository, but in our case we also needed to bypass the status check requirement and there's no exception list for that (yet).

I'm wondering how you configured this. WE're using an app and have added it to Restrict who can push to matching branches and Allow specified actors to bypass required pull requests but I'm still seeing 403 errors.

[mvndaai]

Maybe I am just doing things wrong. I have a dev branch where all PRs get merged onto. Once that is tested and approved I make a PR from dev to main and do a Rebase and merge so the commits get copied over.

This leaves a weird situation where I have dev and main both ahead of and behind each other but with all the same commits, just different hashes. I have been trying to fix it by doing this:

git checkout dev
git pull
git rebase main
git push origin HEAD --force

I was hoping I could have a Github Action that runs on pushes to main that can do that rebase for me only allow that job to do it.

I am fine with anyone running the action whenever. I just want the dev branch to not allow forces in other situations, even from me.

Any tips?

[dough29]

@mvndaai what you expose is not related to this discussion.

By the what you are looking for is something like:

git checkout main
git merge dev

[quentinvedrenne]

@mvndaai did you find or made a GitHub action ?

[Hronom]

Hey, really 5 years for this feature?
It's a basic feature when you need to release library or something.

For example in java there release plugin that need to commit release version, build, push to packages, increase version and commit again.
This is a blocker.

Creation of token from admin account looks like a workaround. Especially that GitHub Actions is the native product of GitHub, it's not third party build system.

[Hronom]

Although I write 5 years, it's actually 4 years issue.
But... given trend - I believe my comment becomes truly valid after Oct 10, 2023. Of-course if GitHub not add solution here before this date

[yannmichaux]

Hey, what do you mean by "creating a token from admin account look like a workaround" ? Can you share something ?
I'm trying to update a dump package.json (npm) on protected branch inside a workflow...

[Hronom]

@yannmichaux I think if you created repo and you admin there, you can go into settings of your account and generate PAT(personal access token) there
and it will allow to do pushes to protected branches, since administrator considered as super user that not affected by the rules of protected branches.
So by using this token as secret in GHA - you can do pushes in protected branch.

Also make sure that in settings of your repository you have unchecked this option:

[piotrekkr]

@yannmichaux Yeah PAT owner need to be repo admin and PAT need to have full repo permissions set. Then you can bypass branch protection rules and push to protected branch directly. If PAT owner have just write permissions it is not enough to bypass protection rules even if you add someone to Allow specified actors to bypass required pull requests section. At least this is my experience.

[hipstersmoothie]

To anyone who need this we just had a contributor add a plugin to our automated release too auto that makes this really easy and I'm sure it could be copied for other's needs.

https://www.npmjs.com/package/@auto-it/protected-branch

It works like this. Once we have all the changes we want committed it:

1. creates a brach
2. opens a pr
3. Approves that branch
4. push happens successfully and branch is closed

Completely automated and you still have branch protection rules

[Naatan]

It's an interesting workaround, but riddling the PR history with this is gonna get annoying real quick :\ Really wish GitHub would just take this issue seriously.

[hipstersmoothie]

yeah it's a little noisy but it's better than nothing!

[ivanbanov]

[kishanbsh-gilead]

There seems to be a possible solution https://github.blog/changelog/2022-08-18-bypass-branch-protections-with-a-new-permission/

[sfonseka-provenir]

isn't this only available for Github Enterprise ?

[kishanbsh-gilead]

Yeah you are right https://stackoverflow.com/a/73410060/3316017

[ViktorDronov]

how can i grant a bot for a custom role?

[asafpelegcodes]

For anyone struggling with this I wanted to share my solution using a Personal Access Token (PAT) that I just got working with a popular library from NPM called release-it.

My workflow is to create tags & releases in github that includes an update to a changelog by a manual run of an action on our protected main branch. Please note that this solution will need to be modified if you want the run to be triggered by a push to the branch otherwise you will create an infinite loop. The provided GITHUB_TOKEN which Github has created for these types of purposes specifically does not trigger further github actions. Hopefully they will fix it in the future.

The special things I had trouble figuring out were

1. Was essential to pass persist-credentials: false to actions/checkout@v2
2. release-it needed to explicitly have set the remote url origin to an address that included the PAT

As mentioned in the other threads/comments the other trick was to add the user that owns the PAT in the setting of the protected branch Allow specified actors to bypass required pull requests.

name: Release Test

on:
  workflow_dispatch:

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
          persist-credentials: false
      - name: git config
        run: |
          git config --global user.name "MyPATAccount"
          git config --global user.email "[email protected]"
          git remote set-url origin https://x-access-token/:${{ secrets.MY_PAT }}@github.com/${{ github.repository }}
      - run: npm ci
      - run: npm run release
        env:
          GITHUB_TOKEN: ${{ secrets.MY_PAT }}

[clemenspeters]

Thanks, this is working for us. With a dedicated bot account (instead of using the personal github account) I think this solution is acceptable for now. 👍

Of course it would be a lot easier if github actions could just be added under "Allow specified actors to bypass required pull requests" without a special PAT 🤔

[piotrekkr]

Does this work for you with some bot user that is not repo admin (normal write repo role)? For me it did not allow to bypass rules even when I added this bot user to Allow specified actors to bypass required pull requests. Seems to me like PAT owner need to be repo admin.

[justin-pierce]

Tried doing this using the new ruleset system, no dice. bot user added to automation team, automation team added to bypass list. read/write contents permission on PAT for bot user, still get 403

[piotrekkr]

Tried doing this using the new ruleset system, no dice. bot user added to automation team, automation team added to bypass list. read/write contents permission on PAT for bot user, still get 403

@justin-pierce

What is the exact error message from git push? It should contain reason why it was rejected.

There is also a chance that you are using both old branch protection and also rulesets at same time. This push error should tell what it is.

[justin-pierce]

@piotrekkr was a newly created test repo so it didn't have any old branch rules. Was unable to access '[url]': The requested URL returned error: 403

creating a github app, using app token, and adding the app to the bypass list worked though.

[AidanWenzel]

Adding my ➕1️⃣ to this - the most secure solution definitely seems like a "allow actions to bypass rules but only for the calling branch". That would improve security over the PR or PAT approaches.

We really could use this for automating manifest updates.

[XDelta]

Adding another +1 here, An idea for additional protection would be requiring the specific action(s) to be set instead of allowing any/all actions on a repo in a given branch to do so.

[shakefu]

"Allow actions (with explicit permissions) to bypass branch protections for the following files only: ... , for only non-PR events, when Github Actions is a CODEOWNER of the file only, and not other files." ... or any Variant thereof.

We just need a special exemption in the Branch Protections that says "Let GHA update this file for version bumps."

[cedric-fauth]

Are there any new workarounds currently on how to bypass branch protection with a gha bot. I have a separate account for a bot which uses a PAT and I want the bot to be able to commit to protected branches but I do not want users to abuse this by creating an action which uses the bot to commit to the same protected branches.

[kartikv11]

This workaround has worked for me, where i wanted to bypass branch protection rules to commit a new version in pom.xml to version upgrade as part of CI:
https://gist.github.com/kartikv11/b565a9c1b9499f6096c380b9c577d762

[seriouslysean]

While I know using PATs is a security risk, I came up with a solution that worked for an open source project that I contribute to where we have a need to auto bump versions on both repo PRs AND forked PRs when they merge to the main branch. Historically using a PAT with one workflow run would fail, as it runs in the context of the forked PR and does not have access to the repo secrets.

In a nutshell, the solve utilizes two workflows:

• One that prepares the version bump that runs in the context of the forked PR and upload an artifact with the version bump type
• One that does the actual bump that runs from a workflow_run trigger, thus in the context of the repo giving it access to secrets

I proofed it out and @itsalaidbacklife and I tested it to ensure it works, and then I implemented it in to the Cuttle app which solved a major problem for us and allows everything to be that much more automated.

Hopefully it helps one of you, too.

[raketeFlo]

In my company we came across the same issue and found a solution which works pretty good and does not require adding a PAT:

1. Create a Github App for your organisation

   • the Github app needs read and write permission for content
   • create a private key for your github app (settings->developer settings->github-apps->your-app)

2. Install the app to the repository where you need to push commits to a protected branch (settings->developer->github-apps->your-app->Install App)

3. Create a environment variable for the APP-ID of your created Github App and a Github secret for the private key created in step 1

4. Enable branch protection rules in your repository and add the Github App to bypass these rules.

5. Within your release.yaml you will have to create a github app installation access token using the create-github-app-token action. This action needs the app-id and the private key from step 3:

steps:
    - uses: actions/create-github-app-token@v1
      id: app-token
      with:
        app-id: ${{ vars.VERSION_BUMPER_APPID }}
        private-key: ${{ secrets.VERSION_BUMPER_SECRET }}

6. Use the generated token to fetch the git history of your repository:

steps:
    - name: Checkout
      uses: actions/checkout@v4
      with:
        fetch-depth: 0
        token: ${{ steps.app-token.outputs.token }}

7. Version Bump and push your changes.

I share with you an example release.yml with lerna as build tool:

name: Publish Packages
on: 
  push:
    branches: 
      - main
      
env:
  GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: 'write'
      packages: 'write'
      actions: 'read'
    steps:
      - uses: actions/create-github-app-token@v1
        id: app-token
        with:
          app-id: ${{ vars.VERSION_BUMPER_APPID }}
          private-key: ${{ secrets.VERSION_BUMPER_SECRET }}
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # pulls all history and tags for Lerna to detect which packages changed
          token: ${{ steps.app-token.outputs.token }}
      # lerna can only add a commit if git user infos are set
      - run: |
          git config user.name github-actions
          git config user.email [email protected]
      
      - name: Install Dependencies
        run: npm ci
        shell: bash

      - name: publish
        uses: actions/setup-node@v4
        with:
          node-version: 20
        env:
          NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - run: npx lerna publish --force-publish --yes

Hope this helps :)

[raketeFlo]

So where do you struggle to specify that the app can bypass? You only have to open the settings page from your public repository and select the app.

[henne49]

I have that as well, the error was:
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes must be made through a pull request.

[piotrekkr]

@henne49 Do you have a ruleset or branch protection rule that adds this PR requirement? If you use both rulesets and normal branch protection rules then they both apply afaik. You should use only rulesets.

[henne49]

I think you are right, I have to remove the branch protection rule and only use the ruleset, thank you! I will test later and let you know

[henne49]

works now

[piotrekkr]

My use case is like this. After someone merge PR to main branch, I want github actions to add/update some repo files and push those to main branch.

I was using branch protection rules with required pull request before merge, one review approval, some PR checks required etc. Probably anyone figured out that GITHUB_TOKEN does not allow to push to protected branch.

My first attempt to fix this was like this:

1. Create a bot user my-bot-user, added it to repo with write permissions (but not as admin)
2. In branch protection rules, add it to list on Allow specified actors to bypass required pull requests.
3. Generated PAT for my-bot-user, with full repo permissions, and put it as repository secret
4. In workflow use this secret as token for checkout action (I did not use the remove credentials option so it was available still after checkout for git to use)
5. Run workflow that updates, commit and push files

Aaaaand... of course it still failed to push to main with

remote: error: GH013: Repository rule violations found for refs/heads/main.        
remote: Review all repository rules at http://github.com/username/my-project/rules?ref=refs%2Fheads%2Fmain        
remote: 
remote: - Changes must be made through a pull request.        
remote: 
remote: - 11 of 11 required status checks are expected.        
remote: 
To https://github.com/username/my-project
 ! [remote rejected]   main -> main (push declined due to repository rule violations)
error: failed to push some refs to 'https://github.com/username/my-project'

I was about to do this ugly brute force fix and add my-bot-user as repo admin but then I remembered something about some (not so) new feature called Rulesets.

Some time ago when I checked what it is, it looked almost exactly as branch protection rules just with different UI. I did not bother with this because I thought there is no real benefit to use those. But there was this one difference I noted. Based on what I saw in ruleset interface you could set some apps or teams to be able to bypass almost all parts of ruleset (not just PR requirements).

So my next step was:

1. Created new team called BOT (idk why but seems like you can only specify teams, roles and apps that can bypass ruleset, not individual accounts)
2. Added my-bot-user to this group
3. Create ruleset with same settings as my branch protection had (same pr requirements, check and so on)
4. Added BOT team as allowed to bypass this ruleset
5. Updated my current branch protection rule renamed branch to main2 so it will not apply to main any more (this is important because (I think) branch protection rules take priority over rulesets)
6. Rerun failing workflow that should modify and push files to main after push event.

And now it works.

remote: Bypassed rule violations for refs/heads/main:        
remote: 
remote: - Cannot update this protected ref.        
remote: 
remote: - Changes must be made through a pull request.        
remote: 
remote: - 11 of 11 required status checks are expected.        
remote: 
To https://github.com/username/my-project
   296055b4..dc09d191  main -> main

It is a PITA that we cannot use Github Action for pushing to protected branch but now at least I found some workaround.

//EDIT

Reading all the answers here it would probably be better to use custom Github app with rulesets instead of PAT with rulesets.

// EDIT 2

Seems like this change works fine for bot user but blocked other devs from actually merging. After some struggle I figured out that Restrict updated is blocking everyone. To fix this I split this one ruleset into three (without using restrict updates)

1. Default branch - require PR & checks (can be bypass by BOT group)
2. Default branch - require linear history
3. Default branch - restrict deletions and force push

Now main is restricted to have linear history and cannot be deleted or force pushed by anyone. Devs can now only update main by creating a pr and passing all required checks and then merging. Bot user can just push to main without any PR requirements.

[imre-h]

Hi, I have implemented the same thing with rulesets, but it does not work. Is the PAT for the bot user still required for this method? Thanks!

[piotrekkr]

@imre-h Hi. BOT user PAT is needed when doing checkout of the code that will then be used by git when pushing (GH needs to know who is pushing).

  update-snapshot:
    name: Update Snapshot
    runs-on: ubuntu-22.04
    timeout-minutes: 10
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          token: ${{ secrets.BOT_USER_PAT }}
          show-progress: false
          ref: ${{ github.event.ref }}
#....

      - name: Commit and push
        uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: "chore: update snapshot"
          file_pattern: "var/Snapshot"
          commit_user_name: bot-username
          commit_user_email: [email protected]
          commit_author: bot-username <[email protected]>

Also check if:

• you don't have normal branch protection rule enabled on default branch
• BOT user is in BOT group
• bot group is added for bypass Default branch - require PR & checks

Also you should have get error message when trying to push and it is rejected. Can you attach this one?

[imre-h]

Hi, thanks, I will try with the PAT.

I thought this is enough but clearly I was wrong and the PAT is needed:

- name: Configure Git user
  run: |
    echo "Configuring Git user"
    git config --global user.name "bot-username"
    git config --global user.email "[email protected]"

My error message:

[piotrekkr]

GitHub must know who is pushing. It can be a user (with PAT), Github Actions app (with GITHUB_TOKEN), some other GH APP (with generated access token) and probably some other ways idk of. By default GH is using GITHUB_TOKEN when checking out the repo code and it stores credentials in git config (unless disabled). Then when using git command it uses those stored credentials to authenticate the push operation. Sadly, afaik GitHub Actions app cannot be added to the bypass list and individual user accounts also cannot be added. So we are forced to use some custom GH App or create a technical bot account and add it to artificial team which then can be added to the bypass list for a ruleset.

Hope using PAT with user inside some team allowed to bypass will help you.