Replies: 59 comments 72 replies
-
Also mentioned and requested here: https://github.community/t/allowing-github-actions-bot-to-push-to-protected-branch/16536 |
Beta Was this translation helpful? Give feedback.
-
Even though it wouldn't work in all use cases for all people, treating the E.g. at my company the |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Yes, GitHub, let's get this feature in please. |
Beta Was this translation helpful? Give feedback.
-
Would also like this implemented. 👍 |
Beta Was this translation helpful? Give feedback.
-
That would be a great GA to implement! |
Beta Was this translation helpful? Give feedback.
-
+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. |
Beta Was this translation helpful? Give feedback.
-
does this fit your need ? https://github.blog/changelog/2022-08-18-bypass-branch-protections-with-a-new-permission/ |
Beta Was this translation helpful? Give feedback.
-
Also interested in a solution - I'm trying to auto bump the version but the branch protection rule I have on |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
I'm running into this issue as well. I use |
Beta Was this translation helpful? Give feedback.
-
Can we bypass the permission rules with Gitbook? We are facing the same issue but within the same company (!) |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
Github, this is a need for full automation after deploys. PLEASE consider this soon. |
Beta Was this translation helpful? Give feedback.
-
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
Now we are using a dedicated github action to push with a particular PAT. We are using
..
|
Beta Was this translation helpful? Give feedback.
-
Need this |
Beta Was this translation helpful? Give feedback.
-
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:
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
For folks that wish to go down the service account PAT route, I found this helpful for authenticating our steps:
- name: Checkout
uses: actions/checkout@v4
with:
token: ${{ secrets.YOUR_SECRET_TOKEN }} The |
Beta Was this translation helpful? Give feedback.
-
After I reviewed all the possible solutions provided, I found this one works fine: I discovered it from this thread: https://github.com/orgs/community/discussions/25305 In my opinion, creating a GitHub App for the organization is better because I can customize the name and permissions. Once I have the App installed, I can make it appear only on specific repositories. The same applies to the App ID and private key, which I can also restrict to specific repositories. Lastly, I can customize the App's logo, allowing us to have a beautiful logo for our bot. |
Beta Was this translation helpful? Give feedback.
-
kind of crazy this has been open for years now, often in actions you're doing CI work and updating branches. yea there are workarounds posted in here but there absolutely should be a checkbox for a built-in mechanism for github actions to bypass branch restrictions. |
Beta Was this translation helpful? Give feedback.
-
There now is the new Do not require status checks on creation option which finally solved this for me: |
Beta Was this translation helpful? Give feedback.
-
+1 -- how is this still not implemented?? |
Beta Was this translation helpful? Give feedback.
-
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):
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.push
events to make sure that they ignore any commits pushed by the service user (the way they'd ignore commits pushed usingGITHUB_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:
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".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.
Beta Was this translation helpful? Give feedback.
All reactions