Run a GitHub action on `pull_request` for PR opened from a forked repo

If I create a workflow with an action that runs on pull_request, when a pull request is opened on that repo from a forked repo, the action is not triggered.

Workflow file:


workflow "List environment variables" {  
on = "pull\_request"  
resolves = ["my-action"]  
}

action "my-action" {  
uses = "./"  
}

Then fork the repo, create a branch, push a commit and open a pull request on the upstream repo. The action is not started for this PR.

Is that intentionnal or is it a limitation of the beta?

If that case is planned to be supported in the future, will the secret environment variables be available to the action?

Thanks!

2 Likes

Hi @pvdlg, that’s intentional and likely to remain the case.

This is a mitigation against the possibility that a bad actor could open PRs against your repo and do things like list out secrets or just run up a large bill (once we start charging) on your account. The actions are in fact executed, but it happens against the _fork_, not against the base repo.

This does require that the forked repo also has actions enabled though. During the beta period that means that the owner of the forked repo must also be in the beta.

Hope this helps clear things up!

5 Likes

Hi,

Is this documented somewhere?

If I setup https://github.com/jessfraz/shaking-finger-action

on pull_request, will the action result show up if somebody with forked repo opens a PR to my repository? Typically I’d like unit tests + linting results to show in the PR automatically.

If it runs against the forked repo, then I assume it is not possible to use the GITHUB_TOKEN to post a comment like in the shaking-finger-action example?

3 Likes

https://developer.github.com/actions/creating-workflows/workflow-configuration-options/#pull-request-events-for-forked-repositories

1 Like

Has there been a change in this policy? I created a test account (@huynguyendev) that is not in the beta. I then opened up a PR to TextureGroup/Texture (which is in the beta) from my forked repo. The commit changes Texture’s worflow file to run on pull_request and voila, the workflow is started for my PR!

https://github.com/TextureGroup/Texture/pull/1628/checks?sha=4f0f4cabd6cbb40224329446e100701ca448353d

Hi @appleton ,

I understand the same. But i think it would be better if atleast the status of the run is shown on the main repository.

The actions run at personal fork but the final status results are shown at the main repository.

1 Like

actions are in fact executed, but it happens against the _fork_

 

How do I (the owner of the fork) see the results of those actions?

This does require that the forked repo also has actions enabled

 

Is there something manual that needs to be done on the forked repo to enable actions?

During the beta period that means that the owner of the forked repo must also be in the beta.

 

I am in the beta but I can not see the results even when I have on: [pull_request, push] set on a pull request in a forked repo. What am I missing?

For the recent update for GitHub Actions we have made a lot of changes to how workflows are run.

A workflow that specifies a pull_request as the event will always run in the repository that contains that pull_request.  So when I raise a pull_request to the upstream repo from a fork of that repo the workflow run will be in that upstream repo.  

https://help.github.com/en/articles/events-that-trigger-workflows#pull-request-events-for-forked-repositories

During the beta you may or may not have GitHub Actions enabled in your user account or organization.  If you don’t have GitHub Actions enabled forking a repo that has actions workflows into your account will not cause any runs to occur.

9 Likes

So how does the mitigation work in this case?

How can I be sure that the author of the PR did not modify the workflow definition and e. g. reads out repository secrets?

I tried this with two accounts that both have Actions enabled:

Create repo for user A

Fork into B’s account

Add a branch, create a PR back into A

… then a push action will run in B, but the results will not be shown in the PR at A.

Or am I misunderstanding something?

1 Like

Secret variables aren’t available on PR by default.

Here is discussion about possibility to pass secret variable to PR: https://github.community/t5/GitHub-Actions/Make-secrets-available-to-builds-of-forks/m-p/30678#M508

3 Likes

Same problem.

Both account with GitHub Action CI enabled but nothing is triggered on the upstream when a PR is made from a fork…

4 Likes

Hi @larshp, are you able to configure the workflow so that unit tests + linting results is shown on the PR when the PR is coming from the forked repo ? … 

Can someone elaborate on whether the marked solution is the current behaviour or the future intended behaviour?

Creating a PR from a fork that has Actions enabled currently does not trigger an actions workflow run on upstream but instead triggers the workflow run on the fork

2 Likes

Hi,

Is this true for private repos?

No matter which combination of advice I take I cannot get my workflow to run from an upstream PR when the branch being PR’d is from a fork (though the PR is open in the upstream repo). I use a workflow for CI to test the PR’d code.

I see that the docs state:

"Note:  Workflows do not run on private base repositories when you open a pull request from a forked repository."

What am I not understanding as this seems ironic to me given that permissions have to be granted to even gain access to the repo? I.e. if I’m ok with them having access, why should I not be ok with them using a workflow?

Thanks

24 Likes

We use local action runners. Does this mean, that every person who has a fork of that repository has to set his own local action runner?

2 Likes

Same confusion here!

I have manually added “collaborators” to my private repo, so I should trust them to send PRs back!

Now I even cannot get the CI on a forked repo working…

Did anyone figure out a workaround for this annoying issue? The only solution I can think of is 1) asking collaborators to send PRs to a dev branch, 2) I merge PRs to trigger CI with a “push to dev” event, and 3) I rebase master onto dev regularly.

1 Like

See https://github.com/nyurik/auto_pr_comments_from_forks – a workaround for this limitation.  Essentially it’s a cron job that frequently checks for recent runs, and posts an artifact content that run has created.

It has been several months and this problem still persists, evidently. Any news on whether this feature will be working for private repos soon?

1 Like

This is how I am creating comments on PRs from forks this using the new pull_request_target event released by GitHub in August 2020:


PS:
Dear GitHub team,

The documentation on pull_request_target and workflow_run events is so confusing. The documentation says that both events can be used to create comments on PRs from forks.

I found workflow_run to be completely insufficient to the task, and there were no examples of how to do it for pull_request_target.

Please consider adding examples when you make claims like that on the documentation. It will save a lot of people a decent amount of time.

1 Like