[BUG] HttpError: Resource not accessible by integration - but it's working at a 2nd call

[joergi]

I was using the labeler quite a while now, so I can have nice labels for my mono-repo.
But since a few weeks I get always(~99%) the same errors (see below), when Dependabot is creating PRs with dependency updates.

If I rerun the check, everything works as expected.
Anyone else having this issue?

triage
HttpError: Resource not accessible by integration

triage
Resource not accessible by integration

My .github/workflows/labeler.yml looks like this:

name: "Pull Request Labeler"
on:
  pull_request:
    branches: [ main ]

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@main
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"
          sync-labels: true

my .github/labeler.yml looks like this:

project1-frontend:
  - services/project1-frontend/**/*

project1-backend:
  - services/project1-backend/**/*
  
project2-frontend:
  - services/project2-frontend/**/*

project2-backend:
  - services/project2-backend/**/*

[TonyArra]

@joergi I believe that this Dependabot change may be the problem? I also have this issue with the autosquash action, but the error message is that the github_token is empty. Manually re-running the checks appears to bypass the issue.

I believe this can be fixed by altering the workflow to make use of the pull_request_target event.

[dannysauer]

I've also been seeing this a lot recently, only with this action (always from Dependabot, too).

It'd be nice if this would log something a bit more helpful in debugging what exactly it is that is not accessible. :)

[joergi]

@dannysauer - was this fix helping you? is it now always green?
and: the security issue documentation is not nice:
The pull_request_target event is granted a read/write repository token and can access secrets, even when it is triggered from a fork.
nothing I really want...

[jsoref]

So, I'd argue that this action should recognize when it's in this state and explain itself.

Basically an action can know which event it's running under (here: pull_request), and it can know which permissions it has/doesn't have (here: it doesn't have pull-requests: write), and it could spit out:

:warning: actions/labeler is running under `on: pull_request` without `permissions: pull-requests: write` and thus can't perform its work. To fix this, someone with write access to the repository will have to update the workflow to apply these changes. Refer to https://github.com/actions/labeler/blob/6a315d4ea58951035b498eef56668feaba24489f/README.md#create-workflow for more information on the recommended content for the workflow which should be helpful in fixing this workflow.

(Whether it hardcodes 6a315d4ea58951035b498eef56668feaba24489f, or uses git rev-parse HEAD / an equivalent environment variable is an implementation detail.)

[MaksimZhukov]

Hello everyone!
For workflows that are triggered by the pull_request event, the GITHUB_TOKEN has read-only permissions in pull requests from forked repositories. Workflows triggered by Dependabot pull requests are treated as though they are from a forked repository, and are also subject to these restrictions. This is the reason why the error occurs.

The pull_request_target event was introduced to enable workflows to label PRs. For workflows that are triggered by this event, the GITHUB_TOKEN is granted read/write repository permission even when they are triggered from a fork. To avoid the error, please update your workflow to use the pull_request_target event (see an example in the README file).

Also, please read the GitHub documentation to be aware of the difference between these events, as well as the pros and cons of each:

1. Keeping your GitHub Actions and workflows secure Part 1
2. The pull_request event
3. The pull_request_target event

I am closing the issue. Please contact us if you have any questions.
Thanks!