Gutenberg: Github actions don't work for pull requests created that involve a fork.

[talldan]

Describe the bug
As explained in the following link, our github actions won't work correctly on PRs where a fork is involved:
https://github.community/t5/GitHub-Actions/GitHub-Action-workflow-is-executed-for-a-PR-from-a-forked-repo/m-p/29579

TLDR - For security reasons, the action itself is run on the forked repo instead of the main repo, and so has no privileges for things like adding labels or milestones.

This is particularly an issue with the First-Time Contributor action, where the majority of PRs that involve first time contributors are from forks.

Ideally we'd be able to find a workaround for this. I've seen it mentioned that the push event can be used. Not entirely sure how that works for forks, perhaps opening the pull request triggers a push event as the base repo has a ref to the head of the branch pushed?

[ScottBrenner]

This behavior has changed recently, it should work using the pull_request event https://help.github.com/en/articles/events-that-trigger-workflows#pull-request-events-for-forked-repositories

[talldan]

It's currently implemented using pull_request, but the issue is that forks only have a read-only token, so can't apply labels. The error shown on a recent PR is:

main: Task addFirstTimeContributorLabel failed with error: HttpError: Resource not accessible by integration

[frextrite]

It's currently implemented using pull_request, but the issue is that forks only have a read-only token, so can't apply labels. The error shown on a recent PR is:

main: Task addFirstTimeContributorLabel failed with error: HttpError: Resource not accessible by integration

I think what @ScottBrenner said was right. The pull_request event is supposed to fire on the base repository (which is what the docs say), however, currently, the event is being fired only when the PR is merged into master. Once that is fixed (unlikely to due security flaws?), the pull_request event workflow would run on the base repository and have the correct permissions for adding labels.

[talldan]

I see now that you'e referring to this part of the docs:

In this scenario, GitHub sends the pull_request event to the base repository and no pull request events occur on the forked repository

Which is unusual because when I checked at the time they were still being triggered from the forked repository, and the action was failing because of the rule.

however, currently, the event is being fired only when the PR is merged into master.

@frextrite what leads you to believe that the action is only triggered on a merge? Currently there's nothing in the way the workflow is configured to restrict when it should run:
https://github.com/WordPress/gutenberg/blob/9030e5198cee60e7c0e49fe919b7fb2e0dffabdc/.github/workflows/pull-request-automation.yml#L1-L14

There's some JavaScript logic so that the action only tries to add a label when a PR is opened:
https://github.com/WordPress/gutenberg/blob/9030e5198cee60e7c0e49fe919b7fb2e0dffabdc/packages/project-management-automation/lib/index.js#L21-L25

[justfathi]

Any update / change to this?

[talldan]

This thread seems to have the latest info from Github as of yesterday (31st Oct '19) - https://github.community/t5/GitHub-Actions/Github-Workflow-not-running-from-pull-request-from-forked/td-p/32979:

Unfortuately we were not able to addres the private repo and private fork scneario. It is something we still do plan to address but I do not have a delivery date at the moment.

[skorasaurus]

@talldan

This can now be resolved using the new pull_request_target ? https://github.community/t/github-workflow-not-running-from-pull-request-from-forked-repository/16379/48
It was just introduced in August.

Check out https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#pull_request_target

[talldan]

That's great, thanks for pointing that out @skorasaurus.

[talldan]

I've made a PR #26876 .