GitHub Community
Workflows vs actions: which permission is correct? #26711
-
|
I want to have a workflow in my repository that periodically updates other workflows in the repository on a semi-weekly basis, so I’m trying to use job control permissions for GITHUB_TOKEN. I have a MWE here: Actions · zkamvar/cautious-octo-chainsaw · GitHub I first tried to use I then tried to use the
How can I write a workflow that has permissions to make pull requests updating other workflows? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
|
The If you want to create a workflow that can update workflow files then you’ll need to provide a Personal Access Token as a secret that grants the |
Beta Was this translation helpful? Give feedback.
-
|
This restriction causes problems for “rebase” actions such as cirrus-actions/rebase. If the upstream repo has workflow changes then rebases of forked PRs get blocked. Using a PAT to work around this is risky, as it gives a long-lived credential to a workflow operating on untrusted data. Is there any way to support this workflow while keeping the benefits of the short-lived github token? |
Beta Was this translation helpful? Give feedback.
-
|
I’d really like github to reassess this issue, and maybe find a way to not trigger infinite loops. Very basic things like needing to auto-update a tag, or do rebases, is causing actions to be unusable without a PAT, if the changes include any changes to a workflow. We shouldn’t be encouraging people to put PATs into their environment across large sets of repos in their organization, because unlike the tokens in the actions, the PATs have much wider access rights, and it will allow repos to modify other repos through their actions. As an example, I want to have a common action for all repos that rebases PRs. Now I need to add a PAT. The only way to sanely do this is to use a PAT that has access to all the repos. Now a developer who only had rights to update a single repo can update every repo that the PAT allows, through their actions. Think about organizations who are using terraform, triggered through github actions. Even running a plan could have side-effects that escalate privileges (and not everyone knows that), so using a PAT like this may give someone with only access to one repo much, much higher privileges. Also, couldn’t you have the same infinite loop situation if the action is changing an action via a PAT? I’m not sure what this is doing other than lowering everyone’s security. |
Beta Was this translation helpful? Give feedback.
-
|
I am currently implementing an Github App replacement of a PAT for this exact use case ( based on https://dev.to/dtinth/authenticating-as-a-github-app-in-a-github-actions-workflow-27co ) However the permission availables for a Github App (which are the same as fine-grained PAT) don't seem to prevent this loop issue. I have allowed for |
Beta Was this translation helpful? Give feedback.
-
|
Just to add my use-case: I uploaded a repo from github.com to our GHES instance. There is no support for forking from cloud into GHES, so I had to do this manually. So looking forward to a solution for this. |
Beta Was this translation helpful? Give feedback.
The
permissionsblock for theGITHUB_TOKENallows you to set the GitHub App permissions for the token. Theactionspermission only grants you some permissions for accessing Actions APIs, but not access to updating workflow files. This is to prevent cases of Actions triggering an infinite loop.If you want to create a workflow that can update workflow files then you’ll need to provide a Personal Access Token as a secret that grants the
workflowscope and use that in place of the provided token.