Token permissions for forks (once again)

I want to raise an issue about the GITHUB_TOKEN permissions for forked repositories again; it was discussed already here and here, but we at @actions-rs are having problems with it right now and there is still no reasonable solution exist.

I understand why forked repos has the read-only permissions, but it is effectively blocks any linters, checkers and audit tools to be implemented as a Github Actions; for example, it’s disallowed to post any data to the Checks API, therefore, it is impossible to create a linter which will validate pull requests from the forked repositories.

Considering how suitable Github Actions are for this kind of stuff, it would be nice to address this problem somehow (by executing Action from the base repository, maybe?).

21 Likes

Hello,

Even I have raised the same issue before here, and I haven’t got any response yet.

Like @svartalf mentioned, Since GITHUB_TOKEN has only  read-only access for the forked repo, it is effectively BLOCKING  to use any PR Labellers, Linters, unit tests, Audit tools as a GitHub Action.

Even the native GitHub Action Labeller fails and doesn’t work  for the forked repos and is been discussed here. The coveralls GitHub Action  also doesn’t post a PR comment for the PR from the forked  repositories. Hence now, with this restriction,  it is impossible to develop a action like labeller which can validate the Pull Requests coming from the forked repositories… 

The same issue is been put up in multiple occasions by different awesome developers in this forum and here is the list: 

  1. https://github.community/t5/GitHub-Actions/Make-secrets-available-to-builds-of-forks/m-p/33885/highlight/true#M1696
  2. https://github.community/t5/GitHub-Actions/optional-read-write-permission-for-forked-repos/m-p/32495#M1159
  3. https://github.community/t5/GitHub-Actions/Github-Workflow-not-running-from-pull-request-from-forked/m-p/33547/highlight/true#M1555
  4. https://github.community/t5/GitHub-Actions/Github-Workflow-not-running-from-pull-request-from-forked/m-p/33816/highlight/true#M1656

 Please kindly take it as HIGH PRIORITY   as it is BLOCKING to use any  audit tools  actions like Labeller, Linters, code coverage actions  for the forked repos and also BLOCKING  the developers to develop any of these kind of  actions . The  GITHUB_TOKEN should at least have  read/write access  for the Pull_Request_comment as this is not critical and won’t have any   write access  to the content of the base repository.  Since, most of the contributions for the open-source project comes from the forked repo , it would be really nice to address this issue somehow.

19 Likes

Hi Vandana.

I think that is a very good point.

We are also facing the same problem in all our open-source projects as  we are unable to use any of the auditing actions like  Labeller or code coverage and unit testing actions because of the restrictions imposed on  the actions for the PR coming from the forked repo.

This is  a  PRIMARY use case and it is stopping us to switch to using these actions for automating the workflow.

If at least the Labeller would be authorized for the PR coming from the forked Repository this would already help to cover some of our use cases.

Kind regards 

Michael

1 Like

Hi Micheal,

Thank you for the support of this feature request. I am glad others are also facing the same issue.  It would be really nice to get a clarification from the GitHub side. 

This is exactly the same issue which we are facing too. All the Pull Request Verification actions like  Labeller , coveralls need at best the read/write access for the Pull_Request_Comment. We currently stalled the development of our  PR workflow automation action due to this constraint for the Pull Request coming from the forks and this is the only Use-Case for us.   

Same issue here, I was trying to build some automation in submariner-io for incoming pull requests, but it’s impossible. I was trying to pass down other secrets… and it didn’t work,

so I thought, let’s use the GITHUB_TOKEN to authenticate via https to the repo (I need to handle some branch details based on PRs) … 

And I discovered this.

We need a solution, I understand the reason, but as people said here, a solution would be enforcing the action to be run from the main repository version, instead from the remote PR.

Would definitely add my confirmation that this is very frustrating and surprising omission. The token for forked repos should at least has read/write for just the checks api. The worst a bad actor could then do is fail his own PR build. I can’t imagine why the checks API has to be read only for forks. It functionally makes github actions unusable for CI.