Github Workflow not running from pull request from forked repository

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.

Some ideas:

  1. Allow adding ‘trusted users’ to the repo / org where they can run workflows

  2. 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)

  3. Provide a manual ‘approve workflow trigger’ button on each PR (only visible by write access people)

  4. 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?

1 Like

Any update? Without PR checks, github actions are virtually useless in private repos.


Hi @chrispat do you have any update on this issue?

This is very annoying to not be able to run the github workflow on pull_request from the original repository.

I would think when using something like "if: github.event.repository.owner.login == … " this would only be triggered  by the repository owner.

The only workaround I can think right now is a **cron** like setup… run from the original repository, but this seems pretty nasty… and will consume a lot of cpu for nothing… 

Do you have a better alternate solution to suggest?

I just want to add this suggestion, just read this blog:

This article seems to suggest that not trigger PR not created by an organization and do a manual CI trigger via comment /ok-to-test.

Interestingly, he mentioned the CODEOWNERS file. I think this is the answer. What if make it a required file for forked PRS. That way, we are assured that the only people who can edit the CODEOWNERS file, which is where the potential secret leak will come from, is listed.

If they are not listed, they can’t edit the workflow folder and sniff out any secrets in the repo.

thanks @thisguychris for the link, interesting to know it s bothering more than one person

but it seems like that part of the reason behind the current behavior is that you do not want a github workflow being altered by third parties… this seems a fair argument… even if GitHub could provide a way to set to always run action from the master branch (for forks only)…

Here is the direction I’m going to use to workardound that limitation:

  • pull requests will not trigger the regular workflow [for all users, better to keep a single/shared workflow than multiples]

  • a pull request will trigger a request to an external api server

  • the external server will use a PAT and do the following actions:

  1. confirm that no changes occurs to the workflow for that pull request

  2. add a comment to the PR using a custom /command to start the workflow

something like “/smoke-me” or other… 

For slash commands depending on your need you can check these two projects:

Hope this could help other persons :slight_smile:

Same problem here when push to master :frowning:

This post was flagged by the community and is temporarily hidden.

Just commenting as this seems to make github actions largely difficult to use. Can’t a forked PR automatically use the workflow from the base repository and run against the remote to make this a non issue?