that will be great and thank you very much for the update …
What a pity - we are going to upgrade our organization to
GitHub Team level, but this feature is very very desirable, since we manage our repos changes using PR’s from forked repos. Any idea when
pull-request event for private repos forks will work?
Hey, @chrispat, do you have anything to share with us? Github Actions will be GAd in a couple of days, right? (Github Universe 2019)?
This is not something we have been able to solve yet unfortuately.
wow, talking about timing, just saw you just replied. I may be oversimplifying things, but if we are concerned on bad actors changing GitHub actions via PR and leak secrets, why not just prohibit all forks from editing a GitHub action? That way, it’s impossible for a bad actor maliciously to change a GitHub action. My issue is PR not being triggered via forks. If it’s read-only then problem solved right?
@thisguychris No it’s not solved since you could still leak secrets from the code that’s being tested.
@bbenoist Again my question is if the secrets are leaking, why does it run on public repos? When you do a PR on a public repo, the action does get triggered. If it’s a security issue shouldn’t it be disabled as well?
Looking forward to hear news about this.
Dear @chrispat ,
Is there any update which you would like to share with us on the GITHUB_ACCESS Token for the Pull Request coming from the forks ?.
This is a must have, as this adds a manual step for reviewers to check action execution results on the forked repo.
How are organizations using GitHub Actions as a CI/CD system if builds can’t run from fork PRs?
Are we now forced back into a feature branching model?
This seems like a pretty big hole. Hoping for an update soon.
So are pull requests from private repository forks still a planned feature, or has that been dropped?
Any news about that? Anyone could workaround it by any settings?
We were looking at switching to GitHub actions from a CI competitor but this is a dead in the water deal breaker. There are so many ways this could be solved but one of them is just an opt-in setting to turn this on. These are all internal employees with forks that have an element of trust established.
Running workflows on a PR from a fork before merge is critical to so many types of workflows.
Any further updates here? This is probably going to drive our 100ish dev team to CircleCI + Gitlab.
Allow adding ‘trusted users’ to the repo / org where they can run workflows
Automatically trigger workflows from forks owned by people with write access (if I’m admin on the base repo, workflows should run from my pull requests from my fork)
Provide a manual ‘approve workflow trigger’ button on each PR (only visible by write access people)
Ability to tag ‘public workflow’ for workflows that aren’t problematic (no secrets involved, just running build / lint / tests).
**bleep**… we switched to Github Action from a legacy plan to the new Teams plan to modernize our build process and we finally have to adapt to an outdated branching model… We need your help Github, bring workflows to forked repos, with something pretty simple at first: only allow usage of read-only features when running workflows from forked PRs for exemple…
Is there any ETA for addressing this issue? Its been a while since last update.
Is there any workaround for this issue?
Any updates here? Are we planning to address the need?