This is the way.

Just let us add GitHub actions to this list:

Thank you @daniel-res 👏 👏

This is the internet's only source for this information

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

Namely:

• Action
• PR
• Contents

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?

Same for me @DoisKoh

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

how did you do it?

Can you please post the workaround

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

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.

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.

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

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

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

+1 for this being part of the permissions in the workflow/action itself. There are some workflows where we want to be able to bypass branch protection rules - but we don't want to just blanket allow all workflows to bypass those protections.

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.

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.

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.

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

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.