-
If I create a workflow with an action that runs on Workflow file:
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! |
Beta Was this translation helpful? Give feedback.
Replies: 19 comments 2 replies
-
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! |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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! |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
How do I (the owner of the fork) see the results of those actions?
Is there something manual that needs to be done on the forked repo to enable actions?
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? |
Beta Was this translation helpful? Give feedback.
-
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. 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. |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
I tried this with two accounts that both have Actions enabled: Create repo for user AFork into B’s accountAdd a branch, create a PR back into A… then a Or am I misunderstanding something? |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
Same problem. Both account with GitHub Action CI enabled but nothing is triggered on the upstream when a PR is made from a fork… |
Beta Was this translation helpful? Give feedback.
-
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 ? … |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
It has been several months and this problem still persists, evidently. Any news on whether this feature will be working for private repos soon? |
Beta Was this translation helpful? Give feedback.
-
This is how I am creating comments on PRs from forks this using the new simiotics/locust/blob/1bebcc2cac67e90c1efb09b42c37e91cdae829f9/.github/workflows/locust.yaml
This file has been truncated. show original PS: 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. |
Beta Was this translation helpful? Give feedback.
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.