No permission to create comment

[sudo-bmitch]

While trying out this action, I'm encountering the error: "GraphQL: Resource not accessible by integration (addComment)".

I tried passing the GITHUB_TOKEN environment variable, setting the pull-requests: write permission on the workflow rather than only the job, and adding the issues: write permission, but so far no luck. My best guess is that the gh command is running in the context of your repository instead of my own.

Here's an example run: https://github.com/regclient/regclient/actions/runs/8484759635/job/23248287252?pr=706

(Note that I have continue-on-error: true defined on the job so that it always shows as successful.)

[captainbeardo]

This set of permissions I have set on my job that works are:

   permissions:
      contents: read
      pull-requests: write
      packages: read
      actions: read

That is only set on the job and I don't pass in GITHUB_TOKEN. I do have the coverage in an entirely separate job than the steps generating the coverage. I don't think that makes it work, but that is a difference.

[fgrosse]

You can see at the top of your run when you expand the "Set up job" step and then click on GITHUB_TOKEN Permissions, that it actually has the wrong permissions (PullRequests: read) for some reason:

Just a hunch but can you check if you defined a variable or secret called GITHUB_TOKEN that is automatically passed into your jobs? You can check here: https://github.com/regclient/regclient/settings/secrets/actions

The reason why I am asking is because GITHUB_TOKEN is listed as environment variable in the log of your job (next to GH_TOKEN):

In my own working tests, the GITHUB_TOKEN is not defined as environment variable to the job step even though I copied your permissions settings.

[sudo-bmitch]

There's no GITHUB_TOKEN secret explicitly defined, that's getting generated by GH for the individual workflow, and the quickly expires. Passing it through was an attempt to fix the issue since I've seen it used on actions like github.com/actions/stale and github.com/softprops/action-gh-release. Setting the top level permissions is flagged by the OpenSSF Scorecard, but they were opened up and retried with different variations without any luck.

[fgrosse]

Not sure how to proceed here as the issue seems to be in your repository or workflow/job configuration.

I checked on a recent job run in your repo and verified the same issue I tried to explain in my last comment. The GITHUB_TOKEN Permissions are set to PullRequests: read but you need write access to comment on PRs.

Interestingly I also found another run in your repository which was triggered by merging into your main branch. In this case, the permissions are set to PullRequests: write.

[fgrosse]

To debug this, you can try if there is any effect when you remove the top-level permissions field. Since you only have a single job in your Coverage Report workflow, it shouldn't actually change any semantics the way I understand it because job level permissions would overwrite default permissions if I understood the help page correctly.

Unfortunately the help doesn't state explicitly what happens if you set both the workflow and job permissions but it says you can either do one or the other but I suppose that's probably not meant in a strict way :shrug:

You can use permissions either as a top-level key, to apply to all jobs in the workflow, or within specific jobs.

Good luck!

[sudo-bmitch]

I checked on a recent job run in your repo and verified the same issue I tried to explain in my last comment. The GITHUB_TOKEN Permissions are set to PullRequests: read but you need write access to comment on PRs.

Looks like that is on the pull request open action, and the branch is my personal fork rather than the regclient project repo, so I'm guessing GitHub security is blocking the GitHub action from getting access to my personal fork, or maybe it's blocking the fork from getting access to the project.

To debug this, you can try if there is any effect when you remove the top-level permissions field.

Removing the top level permissions was one of the things I tested without luck, and adding the write permission there also didn't help.

I'll revisit this later when I have more time to see if I can sort out the difference in token permissions.

[sudo-bmitch]

A quick check of the GITHUB_TOKEN permissions shows that GitHub removes all write access from the token on pull requests from a fork of a public repository. I'm going to need to do some more homework on if I want to change that setting since it's there for security reasons that I probably want.

https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

[fgrosse]

Yeah that makes sense. I didn't really think about forks yet but I think this action wouldn't work well for them exactly because of these (sensible) security defaults :thinking:

[sudo-bmitch]

I believe the workaround would be to use pull_request_target, but that comes with a big security warning to not checkout code that was submitted by the user. The risk is probably fairly small for a job that can only update the pull request and that doesn't execute any of the code that is checked out. But given the added risk I'm going to put this on my backlog to revisit sometime when I have more availability.

Feel free to close this issue out if it's not a scenario you want to work on. Overall, I still think this is a neat idea that fills a need. So even if I'm not able to use it, thanks for creating it!

[fgrosse]

I ended up mentioning this under "Limitations" in the README.md . Thanks again for pointing out this issue and helping to debug it.