Labels are not added on a forked repository

[CsatariGergely]

I have a fork of cntt-n/CNTT in CsatariGergely/CNTT where I would like to test the labeler action before I propose a pr to the upsream repo. I've applied the example from the documentation with some minor changes, but no labels are added to my test pr-s and becouse of #23 I do not know why. Can you please help me to figure out if

• Is it something my labeller.yml?
• Is it becouse my repo is forked? There are some statements about forked repos in #12 , but I do not really understand them. In my case I would like to apply the labels of the forked repo to pr of the forked repo based on actions running in the forked repo. I see no differenve form a forked and a not forked repo in this sense.
• Or what is it?

Thanks

[ekohl]

This is indeed a duplicate of https://github.com/actions/labeler/issues/12

* I see no differenve form a forked and a not forked repo in this sense.

The action runs from the org of the source branch with the permissions of that. Since the fork doesn't have permissions to apply a label, it fails.

[CsatariGergely]

@ekohl #12 have now an comment about everything, so I'm not sure if these are the same.

When a pr is created the action should run on the target repo and target branch not the source.

[ekohl]

That's a limitation of Github Actions and AFAIK not something you can control. My guess is that they chose to do this because of security reasons.

[damianh]

This such an annoying limitiation. The whole github premise is that when creating a fork, even from private repo's in an org, the fork goes to your personal account. It's not even possible to create a fork within the same user or org. This otherwise very useful action is useless for the standard operating proceedure. sigh

[Ecco]

Yes, this is terrible. It's even been reported on this repository as early as #12 , even though this is not specific to this repository.

Actually I took the time to write a comprehensive description of this problem on GitHub Community to explain the whole problem. Feel free to upvote it to raise awareness 😄

[ylemkimon]

tl;dr, change

on:
- pull_request

to

on:
- pull_request_target

---

GitHub has introduced a new event type: pull_request_target, which allows to run workflows from base branch and pass a token with write permission.

In order to solve this, we’ve added a new pull_request_target event, which behaves in an almost identical way to the pull_request event with the same set of filters and payload. However, instead of running against the workflow and code from the merge commit, the event runs against the workflow and code from the base of the pull request. This means the workflow is running from a trusted source and is given access to a read/write token as well as secrets enabling the maintainer to safely comment on or label a pull request. This event can be used in combination with the private repository settings as well.

(Repost from https://github.com/actions/labeler/issues/12#issuecomment-670967607)

[MaksimZhukov]

Hello everyone! This issue has been open for a year without any activity, so I'm going to close it as stale. Please contact us if you have any concerns. Thanks!