When a PR is created by someone who is not a maintainer, getting Resource not accessible by integration

[cunla]

Hi,

I am working on fakeredis-py and using add-pr-comment to add test coverage to PRs - it works very well! (thank you).
When someone not listed as a collaborator on the repository is creating a PR, it fails to create the PR comment with the error Resource not accessible by integration, see example here.

I think this is more of a GitHub issue, but not sure who to refer to.

[kubukoz]

funny thing, I'm also hitting this even when I (a repo admin) open the pull request...

update: my job was limiting its token permissions (having less than the workflow).

[mshick]

Hi @cunla that sounds like it was a permissions issue. Did you get it sorted out? If not I should be able to devote a little more time to this repo in the coming week, and maybe I can dig in further if you have some current (non-expired) logs.

[cunla]

Create a PR on fakeredis (It doesn't have to do anything, just want to give you access to see it real time) - I will approve running the flow and you can see what's going on in the logs.
It only happens when the PR author is not a maintainer of the repo.

[mshick]

@cunla It looks like the issue is the default ${{ secrets.GITHUB_TOKEN }} permissions. I found a clear doc about it here: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

I've also had similar issues on PRs here. The reason: writing a comment requires write permissions on issues, but the default tokens are prohibited from any write permissions on forks from public repos. Even setting granular permissions in the workflow won't do the trick if the workflow is run in the context of the PR itself because the maximum permissions allowed to that token are read-only.

You can try switching to use pull_request_target as the event, which will cause the workflow to run in your branch context — the target of the PR itself. I think that will get the default GITHUB_TOKEN working, or you could optionally provide your own token as a secret on your repo and it will get picked up even if a fork triggered the run.

One minor caveat to pull_request_target that I've noticed is that it makes workflow development somewhat more difficult, since the workflow and action changes in an active PR won't be picked up. Not a huge issue, but worth being aware of.