[bug] Action cannot find labeler.yml config file

[johnnywang]

Describe the bug I've set up the workflow, config file, and submitted several PRs to try testing out the action, only to encounter a "Failed to execute No file named labeler.yml found in .github" error when the action runs

To Reproduce Steps to reproduce the behavior:

1. Set up the labeler action (add workflow, add config file)
2. Submit a test PR
3. Notice that the labeler action fails

Expected behavior The correct labels are added

Screenshots

Additional context My files are set up as follows right now:

repo/.github/workflows/pr-labeler.yml

name: PR Labeler
on:
  pull_request:
    types: [ opened ]

jobs:
  labeler:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Auto Label PR
        id: labeler
        uses: jimschubert/labeler-action@v2
        with:
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

repo/.github/labeler.yml

enable:
  issues: false
  prs: true

labels:
  'bugfix':
    include:
      - '\[(bug|BUG|bugfix|BUGFIX)\]'
    exclude: [ ]
  'mobile':
    include:
      - '\[((platform-|PLATFORM-)?(mobile|MOBILE))\]'
    exclude: [ ]
  'platform':
    include:
      - '\[((platform|PLATFORM)(-server|-SERVER)?)\]'
    exclude: [ ]
  'web':
    include:
      - '\[(web|WEB|platform-client|PLATFORM-CLIENT)\]'
    exclude: [ ]

I definitely see the labeler.yml file in the PR, so I'm not sure why this is failing. I changed it to use pull_request as the only PRs coming in are from our own org, so we don't have to worry about forks. I've also tried this without limiting the perms as I do above to rule that out, and that was still failing.

[jimschubert]

Hey, Johnny.

It should be:

on:
  pull_request_target:
    types: [opened]

You didn't share an example failing PR and your activity history shows as private on your profile. I assume what's happened is you're following a fork/pull model. The pull_request_target event works in the context of the original repo and therefore has access to the GITHUB_TOKEN variable, whereas pull_request works in the context of the contributor's repo. You can only use pull_request when opening a PR directly against the origin repo. It's not really a bug, it's just how the events work. I haven't seen anyone using permissions with this action but I assume the reason you're getting the specific error message is because the GITHUB_TOKEN generated for the fork doesn't have read access to the original/official repo.

Please refer to the official event docs:

I submitted a request for pull_request_target after posting in the community forum and a few months later the feature was available. Prior to this, I'd see similar access errors as you're experiencing. If you get stuck you can check out other repo configs.

On another note since I haven't used the permissions syntax or seen anyone using it with this action, I'd guess you also need issues: read|write since labeling of PRs goes through the issues API. For whatever reason, GitHub API treats issues and PRs both as issues for labeling but not comments. I'd expect after you change to pull_request_target you'd then have an error about failing to persist labels.

If you want to temporarily enable debugging in the labeler code, you can also add LOG_LEVEL: debug. Fair warning… I don't output a ton of debug logs.

Full recommended config:

name: PR Labeler
on:
  pull_request_target:
    types: [ opened ]

jobs:
  labeler:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      issues: read|write
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Auto Label PR
        id: labeler
        uses: jimschubert/labeler-action@v2
        with:
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
          LOG_LEVEL: "debug"

Let me know how that works out.

[johnnywang]

Hey @jimschubert, as mentioned when I first opened this issue, I purposely used pull_target because I'm not forking, and I had also tried without the permissions syntax to rule that out as a problem. I was trying to set this up for use within my org's private repo for PRs that we submit against our own org's master branch.

I actually switched to trying out another action instead, and ran into the same issue, which they actually call out in their docs. Assuming it's the same issue, labeler.yml actually needs to be committed and merged into master first in order to be accessible, with the ones inside a PR being ignored for safety reasons.

[jimschubert]

@johnnywang yes, the calls to get content don't read from PR branches. When you make an unqualified (no branch provided) call to the API for a file, it reads from the default branch whether that's master/main/development/etc.

This might be the same issue encountered by #3 but that user didn't provide any context to suggest there was confusion about how to configure.

I've added a note to the readme via 0527d30bde0.