Gettings Started action broken for PR from fork.
tcapelle opened this issue · comments
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?
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.
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
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
yeah PRs from forks are not authorized to make comments on the base repo, for security reasons. This is to lock things down.
What's your best practice solution to allow this?
It's a GitHub thing, I don't think you can