Workflow check for author association

[n-losse]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

I have seen the announcement that the author_association field on events is deprecated.

The blog post says one should use the REST API as a replacement.

The candidate I see for that is the collaborators. However these require

"Metadata" repository permissions (read)

permissions, and it seems the only way to get these into a workflow is using a PAT. I've tested a workflow with permissions: read-all and it was not allowed, so it seems none of the workflow permissions match that.

Is there any other way to do this without setting a PAT?

Thanks a lot!

[DhruvalAnandkar]

Hi Nikolas! handling github api permissions is honestly such a headache especially when you're trying to keep things secure without messing with PATs.

Great catch testing out the read-all permissions by the way the reason that failed is because the /collaborators endpoint strictly needs push/write access to the repo a standard read-only token just gets blocked by it every single time.

The good news is you don't need a PAT at all and you don't even have to look at the collaborators endpoint.

Just a quick heads-up on that github changelog announcement:--> the deprecation is actually for the public Activity Events API (like when people query GET /events) not the actual webhook payloads that fill out github.event inside your action workflows. So it's definitely worth checking first whether github.event.pull_request.author_association is actually missing for you right now if it's still there, this fetch is just future-proofing rather than a required fix. But if you want to be completely safe against payload changes and still call the REST API like they recommended there's a way simpler workaround. The author_association field is still sitting right there on the Pull Request (or Issue) object if you fetch it straight from the REST API and since just reading a PR only requires basic access, the default GITHUB_TOKEN can handle it perfectly without any extra setup.

Below is the drop-in yaml using the github cli (gh api) to grab that author_association field securely:

jobs:
  check-association:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: read # change to `issues: read` if this is for issues
    steps:
      - name: Fetch author association
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          # pull the PR directly from the API to get the field safely
          ASSOCIATION=$(gh api /repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }} --jq .author_association)
          
          echo "The user ${{ github.actor }} is a $ASSOCIATION"
          
          # now you can use it exactly like before
          if [ "$ASSOCIATION" = "MEMBER" ] || [ "$ASSOCIATION" = "COLLABORATOR" ] || [ "$ASSOCIATION" = "OWNER" ]; then
            echo "they are a core team member!"
          else
            echo "they are an external contributor."
          fi

This keeps your workflow completely future-proof, gets you the exact data you want and also it will avoid personal tokens entirely.

Hope this helps you clear that blocker! let me know how it goes when you drop it into your workflow and if it works out, i'd super appreciate it if you could mark this as the answer!

[n-losse]

Hi Dhruval, thanks a lot! That is excellent information and does indeed solve my problem! Thank you so much!

[n-losse]

Testing out you suggestion I noticed that in fact I was wrong in my previous testing - read-all does give access to /collaborators after all. The real issue was that I'm testing on github enterprise, and that needs extra setup in order to be able to use gh api

  get-collaborators:
    runs-on: self-hosted
    steps:
    - name: collaborators-endpoint
      env:
        GH_ENTERPRISE_TOKEN: ${{ github.token }}
      run: |
        export GH_HOST="${GITHUB_SERVER_URL#https://}"
        gh api repos/${{ github.repository }}/collaborators | jq

This actually works with read-all.

Keeping your solution since the PR API is in fact the nicer way to go.