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).

[NobbZ]

Option 1 makes this action useless, as whoever who has write access can put the labels themselves as necessary, though in a repo with 90 percent or more contribution through forks, we really wanted to use this action to reduce manual work.

Why can't you just use the default branches labeler.yml as canonical config?

[damccorm]

Yeah, agreed option 2 makes a lot more sense.

Why can't you just use the default branches labeler.yml as canonical config?

The issue isn't getting the labeler.yml, the issue here is that workflows that run on forks don't have write permissions (so they can't create labels)

[iHiD]

Could we change the config to use the repo's token, rather than the fork's token? If this works conceptually, we (exercism pps) could experiment more.

[ibakshay]

Hello @damccorm, Is there any way or workaround to trigger the action on the base repository so that the GitHub Action token will have both read/write access when there is a PR from the forked repository. And there is no need to re-write the whole code base.

[GregTheGreek]

What is the end solution?

[pedronastasi]

Apparently, GitHub is treating dependabot prs like forks. Here is the related article. As @TobKed has suggested, I used the following snippet on the top level of my workflow to grant the needed permissions. So thank you very much.

permissions:
  # All other permissions are set to none
  checks: write
  contents: read
  pull-requests: write

Additional question to @TobKed assuming that the repository will always be private and I will only use dependabot to update private submodules that my repository is dependent to, do you think it is also possible/safe to use pull_request_target as my event trigger without adding any permissions like you have suggested?

pull_request_target is not safe and not recommended at all as it compares all the changes against master, which makes the tests unreliable.