GitHub Action workflow is executed for a PR from a forked repo if the PR changes the workflow file #25198
-
According to this thread, actions of a PR from a fork repo will be executed against the fork, and only if the fork is in the beta program. I tested this by creating a test account (@huynguyendev) that is not in the beta. I then opened up a pull request to TextureGroup/Texture (which is in the beta) from my forked repo. The commit changes Texture’s worflow file to add pull_request event and voila, the workflow is now executed on my PR. This has the potential of allowing bad actors to run their own scripts by simply opening up PRs on open source projects. Can someone verify if this is in fact intended behavior? |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 1 reply
-
It allows bad actors to run their own scripts, but only in the context of their own repository. Basically, it works like this:
Leaving aside the “which repo is in the Actions beta” part, the workflow executes in I hope that helps to clarify things. |
Beta Was this translation helpful? Give feedback.
-
Is this still the case? |
Beta Was this translation helpful? Give feedback.
-
This is still the case. Forked repositories only have a read-only version of the repository token so that they can do a clone, and do not get a copy of workflow secrets. |
Beta Was this translation helpful? Give feedback.
-
Builds should still be triggered even in forks, right? Somehow I don’t see any builds for a fork in this PR vega/vega-lite#5438. Is there a setting to enable builds on forks? |
Beta Was this translation helpful? Give feedback.
-
This limited support for forks is a big adoption problem, I hope you see it. I wrote a blog post about it where I not only complain but also suggest a very handy possible solution that you could copy from other tools - https://dev.to/derberg/github-actions-when-fascination-turns-into-disappointment-4d75. I hope this helps, somehow. |
Beta Was this translation helpful? Give feedback.
-
As we mentioned in other threads that you’re in - this is something that we’re investigating and working on. In the meantime, you’re welcome to implement exactly the proposal that you describe in your blog post. You can trigger a workflow on an issue comment, examine that issue comment for |
Beta Was this translation helpful? Give feedback.
-
Interesting. But how would I integrate it with pull requests? For example. I need to enable static code analysis with eslint, and want it on PR of course. So I would have eslint as part of the workflow that is triggering on issue comment? and I would somehow reference the PR number in the issue comment, so the workflow knows what repo and branch to checkout? |
Beta Was this translation helpful? Give feedback.
-
@ethomson, We are also facing the adoption problems for quite some time (nearly 5 months). Our GitHub Action progress is in a standstill due to this limitation. Can you give us an ETA ? So that I can pass it on to my colleagues. |
Beta Was this translation helpful? Give feedback.
It allows bad actors to run their own scripts, but only in the context of their own repository. Basically, it works like this:
foo/bar
existsfoo/bar
tolee-dohm/bar
lee-dohm/bar
and open a pull request tofoo/bar
Leaving aside the “which repo is in the Actions beta” part, the workflow executes in
lee-dohm/bar
even though the result is visible infoo/bar
. This means that I can’t create a workflow that emails thesecrets
offoo/bar
to me by creating a PR because it would email me thesecrets
oflee-dohm/bar
.I hope that helps to clarify things.