Gettings Started action broken for PR from fork.

[tcapelle]

Hello. This is more a question about how to do this... I am trying to create a small Action that would post a comment on a PR after it has been created, but I have no success if the PR comes from a fork. I am using the "getting started" action from the documentation. I get the following error:

>> Creating comment on PR #225
[532](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:532)
Traceback (most recent call last):
[533](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:533)
  File ".github/scripts/open_in_colab.py", line 57, in <module>
[534](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:534)
    create_comment()
[535](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:535)
  File ".github/scripts/open_in_colab.py", line 55, in create_comment
[536](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:536)
    api.issues.create_comment(issue_number=issue, body=body)
[537](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:537)
  File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/ghapi/core.py", line 63, in __call__
[538](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:538)
    return self.client(self.path, self.verb, headers=headers, route=route_p, query=query_p, data=data_p)
[539](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:539)
  File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/ghapi/core.py", line 108, in __call__
[540](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:540)
    res,self.recv_hdrs = urlsend(path, verb, headers=headers or None, debug=self.debug, return_headers=True,
[541](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:541)
  File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/fastcore/net.py", line 212, in urlsend
[542](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:542)
    return urlread(req, return_json=return_json, return_headers=return_headers)
[543](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:543)
  File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/fastcore/net.py", line 113, in urlread
[544](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:544)
    if 400 <= e.code < 500: raise ExceptionsHTTP[e.code](e.url, e.hdrs, e.fp) from None
[545](https://github.com/wandb/examples/runs/5813246392?check_suite_focus=true#step:4:545)
fastcore.basics.HTTP403ForbiddenError: HTTP Error 403: Forbidden

Do I need to change something in the admin of the repo?

[tcapelle]

I checked our admin preferences, and we have the following:

That looks very reasonable...

For me, the problem is that when you authenticate using github_token() it appears that you are not allowed to write issue comments if you come from a fork.

[tcapelle]

Link to the failing demo repo: https://github.com/tcapelle/pr_action/runs/5849112784?check_suite_focus=true

can you take a look @hamelsmu please, I don't know how to debug this.

It appears to be related to this: https://stackoverflow.com/questions/70435286/resource-not-accessible-by-integration-on-github-post-repos-owner-repo-ac

[tcapelle]

It appears that the GITHUB_TOKEN does not have issues write permissions when ran from a fork:

It appears the way to achieve this is:

The other answers don't mention is the security restrictions of a GitHub action run from a fork that triggers the pull_request event. The GITHUB_TOKEN in these actions does not have write access to the repository and therefore cannot create a comment. See permissions for the GITHUB_TOKEN.

The GitHub docs for the workflow_run event have a good example of how to work around this. The basic idea is to have the workflow that is triggered by the pull_request event upload any info needed in the comment as a build artifact using actions/upload-artifact. Then a separate workflow triggered by a workflow_run event downloads the information using actions/download-artifact.

NOTE: For security, since the workflow triggered by workflow_run has write access, it must be committed to the default branch before it can be used. (Also keep in mind that the build artifacts could contain malicious data from a malicious pull request).

from: https://stackoverflow.com/questions/58066966/commenting-a-pull-request-in-a-github-action

[hamelsmu]

yeah PRs from forks are not authorized to make comments on the base repo, for security reasons. This is to lock things down.

[tcapelle]

What's your best practice solution to allow this?

[hamelsmu]

It's a GitHub thing, I don't think you can