Can GITHUB_TOKEN be used in place of PAT (github update)

[dhruvparanjape]

Hi love this action 🍻

based on this post from github https://github.blog/changelog/2022-09-08-github-actions-use-github_token-with-workflow_dispatch-and-repository_dispatch/

I was wondering does this mean its possible to use this action entirely with just the GITHUB_TOKEN secret and no longer require a PAT ?

[dhruvparanjape]

spoiler alert it seems it does work as expected 👍

[peter-evans]

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]

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) 🚀

[terrabitz]

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)

[geemus]

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

[steve-todorov]

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

@peter-evans The way to reproduce this is by going to the GraphQL Explorer and typing this:

query {
  repository(owner: "x", name: "y") {
    collaborators(query: "z") {
      edges {
        permission
      }
    }
  }
}

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:

{
  "data": {
    "repository": {
      "collaborators": {
        "edges": [
          {
            "permission": "ADMIN"
          }
        ]
      }
    }
  }
}

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)

[geemus]

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

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.

run: echo "GITHUB_TOKEN=${{ steps.generate_token.outputs.token }}" >> $GITHUB_ENV