GitHub Community
-
|
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? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 39 comments 104 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
For anyone else looking for the "true" accepted answer, this is what worked for us: https://github.com/orgs/community/discussions/25305#discussioncomment-8256560 |
Beta Was this translation helpful? Give feedback.
-
|
@chrispat is there any way you could consider updating the accepted answer to something like the one I linked to? Thanks! |
Beta Was this translation helpful? Give feedback.
-
Can someone explain how this would work? |
Beta Was this translation helpful? Give feedback.
-
|
I think that @chrispat did not properly understand the use case here. The comments above provide some good arguments why this feature is needed. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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! |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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? |
Beta Was this translation helpful? Give feedback.
-
|
hi… did you figure out why this happens? I have the same issue. |
Beta Was this translation helpful? Give feedback.
-
|
btw, I found a solution by reading the documentation of:
cycjimmy/semantic-release-actionGitHub Action for Semantic Release. Contribute to cycjimmy/semantic-release-action development by creating an account on GitHub. it is important to either set the |
Beta Was this translation helpful? Give feedback.
-
|
@itsalaidbacklife i tried the same but still get the same error. is something else needed? |
Beta Was this translation helpful? Give feedback.
-
|
@ghcsimon2 I put together an example repo with workflows that @itsalaidbacklife and I use on Cuttle. Hope it helps! |
Beta Was this translation helpful? Give feedback.
-
|
Yes thank you @tripodsan, this is exactly what I needed! |
Beta Was this translation helpful? Give feedback.
-
|
@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? |
Beta Was this translation helpful? Give feedback.
-
|
@craigbroadman all it needs in the case I wrote about is to read meta data and read and write code.
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Is there still no option here that doesn’t require the anti-pattern of creating a bot user just to work around Github limitations? |
Beta Was this translation helpful? Give feedback.
-
|
@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? |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
@itsalaidbacklife |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? Or something like this? Here this also mentioned https://github.com/orgs/community/discussions/25305#discussioncomment-3247415 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
cc @chrispat |
Beta Was this translation helpful? Give feedback.
-
|
Maybe I am just doing things wrong. I have a This leaves a weird situation where I have I was hoping I could have a I am fine with anyone running the action whenever. I just want the Any tips? |
Beta Was this translation helpful? Give feedback.
-
|
@mvndaai what you expose is not related to this discussion. By the what you are looking for is something like:
|
Beta Was this translation helpful? Give feedback.
-
|
@mvndaai did you find or made a GitHub action ? |
Beta Was this translation helpful? Give feedback.
-
|
Hey, really 5 years for this feature? For example in java there release plugin that need to commit release version, build, push to packages, increase version and commit again. 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. |
Beta Was this translation helpful? Give feedback.
-
|
Although I write 5 years, it's actually 4 years issue. |
Beta Was this translation helpful? Give feedback.
-
|
Hey, what do you mean by "creating a token from admin account look like a workaround" ? Can you share something ? |
Beta Was this translation helpful? Give feedback.
-
|
@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 Also make sure that in settings of your repository you have unchecked this option: |
Beta Was this translation helpful? Give feedback.
-
|
@yannmichaux Yeah PAT owner need to be repo admin and PAT need to have full |
Beta Was this translation helpful? Give feedback.
-
|
To anyone who need this we just had a contributor add a plugin to our automated release too https://www.npmjs.com/package/@auto-it/protected-branch It works like this. Once we have all the changes we want committed it:
Completely automated and you still have branch protection rules |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
yeah it's a little noisy but it's better than nothing! |
Beta Was this translation helpful? Give feedback.
-
|
There seems to be a possible solution https://github.blog/changelog/2022-08-18-bypass-branch-protections-with-a-new-permission/ |
Beta Was this translation helpful? Give feedback.
-
|
isn't this only available for Github Enterprise ? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah you are right https://stackoverflow.com/a/73410060/3316017 |
Beta Was this translation helpful? Give feedback.
-
|
how can i grant a bot for a custom role? |
Beta Was this translation helpful? Give feedback.
-
|
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 The special things I had trouble figuring out were
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 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 }} |
Beta Was this translation helpful? Give feedback.
-
|
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 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
@piotrekkr was a newly created test repo so it didn't have any old branch rules. Was creating a github app, using app token, and adding the app to the bypass list worked though. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
"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." |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
This workaround has worked for me, where i wanted to bypass branch protection rules to commit a new version in |
Beta Was this translation helpful? Give feedback.
-
|
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:
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. |
Beta Was this translation helpful? Give feedback.
-
|
In my company we came across the same issue and found a solution which works pretty good and does not require adding a PAT:
steps:
- uses: actions/create-github-app-token@v1
id: app-token
with:
app-id: ${{ vars.VERSION_BUMPER_APPID }}
private-key: ${{ secrets.VERSION_BUMPER_SECRET }}
steps:
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0
token: ${{ steps.app-token.outputs.token }}
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 :) |
Beta Was this translation helpful? Give feedback.
-
|
works now |
Beta Was this translation helpful? Give feedback.
-
|
This worked perfectly for me, thank you so much 🙇 |
Beta Was this translation helpful? Give feedback.
-
|
With rulesets, deploy keys may be used as bypass instead of a GitHub App: 
|
Beta Was this translation helpful? Give feedback.
-
@ushuz Would this "Deploy keys" method work when using |
Beta Was this translation helpful? Give feedback.
-
|
@navtoj Yes! See my answer below: https://github.com/orgs/community/discussions/25305#discussioncomment-10728028 |
Beta Was this translation helpful? Give feedback.
-
|
My use case is like this. After someone merge PR to 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 My first attempt to fix this was like this:
Aaaaand... of course it still failed to push to I was about to do this ugly brute force fix and add 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:
And now it works. 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
Now |
Beta Was this translation helpful? Give feedback.
-
|
for me using the PAT worked |
Beta Was this translation helpful? Give feedback.
-
|
It seems like I did it the same way as Imre-H. I added the automation bot user to the team that has admin access and I created the bypass list and used the PAT, but I'm still getting the same error. It's really weird because the PAT works fine on my local computer, but it's not working in the workflow, and I'm encountering the same error as mentioned above. |
Beta Was this translation helpful? Give feedback.
-
|
PAT does not need to be of a user with admin. Need only write access. Can you prepare some simplified version of workflow that basically,
Like simple example just to be sure that nothing else can interfere. Also provide error message. You can also export rules you have set on default branch. And be sure you don't have normal branch protection enabled. |
Beta Was this translation helpful? Give feedback.
-
|
My problem was on the checkout that should use the PAT. |
Beta Was this translation helpful? Give feedback.
-
|
To get rid of PAT token (for the sake of security) feel free to use my access token action https://github.com/qoomon/actions--access-token |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
The cleanest way I have found is to have GHA to actually open a PR and merge that PR, as outlined in @chrispat's answer. It's very easy with the I had to give permissions to create and merge PRs to GitHub Actions in the repo's settings. |
Beta Was this translation helpful? Give feedback.
-
|
This'll work if you don't need the PR merge to trigger actions in other repos. Since actions by the |
Beta Was this translation helpful? Give feedback.
-
|
I think @ushuz's comment is the best solution so far and deserves to be highlighted: Deploy keys can be added to rulesets' Bypass list! So this is what worked for me:
I've created a repo that that tests this setup here: https://github.com/sbellone/release-workflow-example |
Beta Was this translation helpful? Give feedback.
-
|
This is probably the best workaround/solution until GH actually allows actions to be on the bypass list. One caveat that should be called out: actions taken by the deploy key will appear (in most places) to have been done by the user that created the deploy key. In other words, say I ( 
|
Beta Was this translation helpful? Give feedback.
-
|
In my case, following the repo example provided by @sbellone it shows the configured user as the commit author: 
|
Beta Was this translation helpful? Give feedback.
-
|
@zhimsel was talking about the audit log, the commits themselves are indeed authored by the configured used 👌 |
Beta Was this translation helpful? Give feedback.
and others
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.