starter-workflow template gives `Resource not accessible by integration`

[msamprz]

Hi there,

I've implemented the exact Labeler workflow as the starter-workflow template in the dir path .github/workflows/label.yml.

I have also added the .github/labeler.yml file with the configuration below:

Trader: packages/trader/**/*

Bot: packages/bot/**/*

Core: packages/core/**/*

Components: packages/components/**/*

Shared: packages/shared/**/*

The action is recognised and runs on PR, however the Labeler action resolves with the following error:

##[error]HttpError: Resource not accessible by integration
##[error]Resource not accessible by integration
##[error]Node run failed with exit code 1

Googling seems to relate that error with invalid access to the repo by the action app, so I thought I'd create an issue and disable the action for now, but would be happy to know if there's something I have missed out that will be able to solve this issue for me.

Thanks.

[damccorm]

Hm, haven't seen that before. Are you able to share your repo by chance (or just the relevant pieces)?

[msamprz]

Hey @damccorm, thanks for the response.
Yes, sure. The repo is over at github.com/binary-com/deriv-app. Although due to the failing action, we have currently disabled it, but you can find the PR that enabled Labeler here, and an example of a failed run here.

[damccorm]

Hm, so it looks like this is an issue with forks:
works fine on my branch
fails on fork

I'll reach out internally and figure out if that's expected scoping of permissions for the GITHUB_TOKEN and we can go from there

[squidsoup]

I just submitted a support ticket about this, but probably should have checked here first! thanks @damccorm

[damccorm]

So it turns out that this is working as intended after all. We can't give write permissions to forks for security reasons (e.g. the forked user changes your yaml file to write bad things to your repo), so this should fail on forks.

With that said, the docs are wrong here and need to be updated. Already added actions/starter-workflows#78 to update the template, will also follow up to update docs here.

[msamprz]

Thanks for investigating, @damccorm. And the update seems like a good alternative for my use at least. Others can reopen this if necessary, but I'll close it as it's expected behavior.

Just pinging you, @squidsoup to loop you in.

[damccorm]

I spoke too soon. Switching this to cron by itself won't work because we assume its going to be run on a PR. Trying to figure out what makes the most sense here. Option 1 is to just not add labels to forks (but we shouldn't throw like we do now regardless). Option 2 is to update it to filter through all pull requests.

In theory I like option 2, but we need to be careful or we'll get rate limited - along those lines, we need a way of skipping PRs that we've already processed - maybe we could add a "triaged" label or something, but that's kind of ugly.

Thoughts? My instinct is to start with option 1 - better error handling on forks - and then move on to option 2 as appropriate

[squidsoup]

@damccorm option 2 certainly sounds far more useful for us - our workflow has every developer on our project making PRs from their forks (and presumably that's a fairly common workflow).