You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Can GITHUB_TOKEN be used in place of PAT (github update) #147
I saw that blog post, too. Thank you for testing it!
I've not had chance to test it myself yet, but my guess is that there are still situations where you might need a PAT. For example, if the dispatch is to a remote repository, not the local one associated with the GITHUB_TOKEN. So there are a few things I want to test before updating documentation, or even the action itself.
Heya! Just wanted to chime in here and also confirm that it seems to work as expected with a GITHUB_TOKEN as long as your workflow is on the current repo (private or public) 🚀
Just to throw my 2 cents here, I found that I was able to run using the GITHUB_TOKEN, but it needed a couple extra permissions to do so:
permissions:
pull-requests: write # For doing the emoji reaction on a PR comment
issues: write # For doing the emoji reaction on an issue comment
contents: write # For executing the repository_dispatch event
This will only work for the local repository though. If you want to call a remote repo, you have to use a classic PAT. (The new fine-grained PATs won't work until GitHub adds support for them in the GraphQL API)
When I tried to do this, I unfortunately have had a bit less luck. I tried passing the GITHUB_TOKEN with and without permissions and in both cases ended up with Command '...' is not configured for the user's permission level 'none'.. I also tried changing the permission to none, but then I just end up with an error about the resource not being accessible. Any advice on what I might be missing?
We previously had it working with a PAT_TOKEN, which we can certainly switch back to, I just thought this might be a bit nicer (and would stop claiming everything was being done on behalf of the PAT_TOKEN owner).
@geemus 3 weeks ago I was here and attempted @terrabitz 's solution which worked fine on a public repository. Today I was doing the same for a PRIVATE repository and encountered your problem. It looks like this specifically doesn't work for PRIVATE repositories.
My guess is the issued gh token via the permissions key does not actually contain the collaborator permission json that is expected by the typescript.
The only way it works with a private repository is by using PAT from a bot.
When logging into the GQL Explorer be sure to be a member of an organization which does not allow the GraphQL API Client access. After executing the query against an organization to whom you are a member and have allowed access you will get something like this:
But when you query an organization which you have not allowed GraphQL to query you will get something like this:
{
"data": {
"repository": {
"collaborators": {
"edges": [
// from memory I believe this was empty or the "permission" key was just an empty string.
]
}
}
}
}
What's interesting is that public repositories work just fine (here's an example of s3fs-nio where we're using it with permissions instead of PAT)
@steve-todorov thanks for the detailed additional info, I was definitely also trying to do this on a private repo when I saw the issue as you had surmised.
if the dispatch is to a remote repository, not the local one associated with the GITHUB_TOKEN.
We created a GitHub App and used https://github.com/tibdex/github-app-token to generate a new GITHUB_TOKEN to use in the rest of our workflow. That GitHub App was then granted the necessary roles/permissions to do what it needed.
The downside is that we had to feed a secret (the private_key value) into the action via an org-level secret. But it was easy enough to then use the generated token in the rest of the workflow's steps. The step after using tibdex/github-app-token rewrites the env.GITHUB_TOKEN with the new one.
Activity
dhruvparanjape commentedon Sep 9, 2022
spoiler alert it seems it does work as expected 👍
peter-evans commentedon Sep 13, 2022
Hi @dhruvCW
I saw that blog post, too. Thank you for testing it!
I've not had chance to test it myself yet, but my guess is that there are still situations where you might need a PAT. For example, if the dispatch is to a remote repository, not the local one associated with the
GITHUB_TOKEN. So there are a few things I want to test before updating documentation, or even the action itself.rijkvanzanten commentedon Feb 28, 2023
Heya! Just wanted to chime in here and also confirm that it seems to work as expected with a
GITHUB_TOKENas long as your workflow is on the current repo (private or public) 🚀terrabitz commentedon Mar 29, 2023
Just to throw my 2 cents here, I found that I was able to run using the
GITHUB_TOKEN, but it needed a couple extra permissions to do so:This will only work for the local repository though. If you want to call a remote repo, you have to use a classic PAT. (The new fine-grained PATs won't work until GitHub adds support for them in the GraphQL API)
geemus commentedon May 11, 2023
When I tried to do this, I unfortunately have had a bit less luck. I tried passing the
GITHUB_TOKENwith and without permissions and in both cases ended up withCommand '...' is not configured for the user's permission level 'none'.. I also tried changing the permission tonone, but then I just end up with an error about the resource not being accessible. Any advice on what I might be missing?We previously had it working with a PAT_TOKEN, which we can certainly switch back to, I just thought this might be a bit nicer (and would stop claiming everything was being done on behalf of the PAT_TOKEN owner).
steve-todorov commentedon May 30, 2023
@geemus 3 weeks ago I was here and attempted @terrabitz 's solution which worked fine on a public repository. Today I was doing the same for a PRIVATE repository and encountered your problem. It looks like this specifically doesn't work for PRIVATE repositories.
My guess is the issued
gh tokenvia thepermissionskey does not actually contain the collaborator permission json that is expected by the typescript.The only way it works with a private repository is by using PAT from a bot.
@peter-evans The way to reproduce this is by going to the GraphQL Explorer and typing this:
When logging into the GQL Explorer be sure to be a member of an organization which does not allow the GraphQL API Client access. After executing the query against an organization to whom you are a member and have allowed access you will get something like this:
But when you query an organization which you have not allowed GraphQL to query you will get something like this:
What's interesting is that public repositories work just fine (here's an example of s3fs-nio where we're using it with
permissionsinstead ofPAT)geemus commentedon May 30, 2023
@steve-todorov thanks for the detailed additional info, I was definitely also trying to do this on a private repo when I saw the issue as you had surmised.
tgharold commentedon Jun 28, 2023
We created a GitHub App and used https://github.com/tibdex/github-app-token to generate a new GITHUB_TOKEN to use in the rest of our workflow. That GitHub App was then granted the necessary roles/permissions to do what it needed.
The downside is that we had to feed a secret (the private_key value) into the action via an org-level secret. But it was easy enough to then use the generated token in the rest of the workflow's steps. The step after using
tibdex/github-app-tokenrewrites the env.GITHUB_TOKEN with the new one.run: echo "GITHUB_TOKEN=${{ steps.generate_token.outputs.token }}" >> $GITHUB_ENVMoulick commentedon Mar 21, 2026
Using the
GITHUB_TOKENfor triggering the repository dispatch workflows within the same organizational repo of typeInternalworks just fine now