Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Github actions don't work for pull requests created that involve a fork. #17324

Closed
talldan opened this issue Sep 4, 2019 · 9 comments · Fixed by #26876
Closed

Github actions don't work for pull requests created that involve a fork. #17324

talldan opened this issue Sep 4, 2019 · 9 comments · Fixed by #26876
Assignees
Labels
[Status] In Progress Tracking issues with work in progress [Type] Automated Testing Testing infrastructure changes impacting the execution of end-to-end (E2E) and/or unit tests. [Type] Bug An existing feature does not function as intended

Comments

@talldan
Copy link
Contributor

talldan commented Sep 4, 2019

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?

@talldan talldan added [Type] Bug An existing feature does not function as intended [Type] Automated Testing Testing infrastructure changes impacting the execution of end-to-end (E2E) and/or unit tests. labels Sep 4, 2019
@ScottBrenner
Copy link

ScottBrenner commented Sep 27, 2019

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
Copy link
Contributor Author

talldan commented Sep 28, 2019

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
Copy link

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
Copy link
Contributor Author

talldan commented Oct 5, 2019

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:

on: pull_request
name: Pull request automation
jobs:
pull-request-automation:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
# Changing into the action's directory and running `npm install` is much
# faster than a full project-wide `npm ci`.
- run: cd packages/project-management-automation && npm install
- uses: ./packages/project-management-automation
with:
github_token: ${{ secrets.GITHUB_TOKEN }}

There's some JavaScript logic so that the action only tries to add a label when a PR is opened:

{
event: 'pull_request',
action: 'opened',
task: addFirstTimeContributorLabel,
},

@justfathi
Copy link

Any update / change to this?

@talldan
Copy link
Contributor Author

talldan commented Nov 1, 2019

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.

@talldan
Copy link
Contributor Author

talldan commented Nov 11, 2020

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

@talldan talldan removed the [Status] Blocked Used to indicate that a current effort isn't able to move forward label Nov 11, 2020
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Nov 11, 2020
@talldan
Copy link
Contributor Author

talldan commented Nov 11, 2020

I've made a PR #26876 .

marcotc added a commit to DataDog/dd-trace-rb that referenced this issue Dec 7, 2020
Reference issue: WordPress/gutenberg#17324 (comment)

Because the GitHub Action runs on our repository, it doesn't have permission to modify a community pull request, as those belong to the original forked repository.

This PR solves that by running the Action in the context of the original repository, by triggering from the `pull_request_target` event, instead of `pull_request`.
marcotc added a commit to DataDog/dd-trace-rb that referenced this issue Dec 8, 2020
Reference issue: WordPress/gutenberg#17324 (comment)

Because the GitHub Action runs on our repository, it doesn't have permission to modify a community pull request, as those belong to the original forked repository.

This PR solves that by running the Action in the context of the original repository, by triggering from the `pull_request_target` event, instead of `pull_request`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Status] In Progress Tracking issues with work in progress [Type] Automated Testing Testing infrastructure changes impacting the execution of end-to-end (E2E) and/or unit tests. [Type] Bug An existing feature does not function as intended
Projects
None yet
6 participants