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!

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

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.

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.

@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.

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.

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.

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.

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.

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?

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.

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

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

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 "MyPATAccount@example.com"
          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 }}

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.

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 github-actions@github.com
      
      - 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 :)