Github Workflow not running from pull request from forked repository

I have a Github Workflow that is triggered on a pull request like so:

on: [pull_request]

 But when I open a PR from my forked repository to the upstream repository, the Github Action is not being triggered on the upstream repository.

From what I’ve read in the documentation here, it seems like the Workflow should be triggered, but the only time that it is triggered is on the merging of the pull request into the upstream repository.

When you open a pull request from a forked repository, the pull request opens on the base repository by default. In this scenario, GitHub sends the pull_request event to the base repository and no pull request events occur on the forked repository because the webhook configuration of the original base repository doesn't apply to forked repositories.

I’d like to confirm what the correct behaviour is here. I have Github Actions enabled on both my user account and the upstream repositories account. 


I am getting the same problem. Although, my action is triggerd in my forked repository insted of upstream. Both are private. I need to figure out how to trigger build on upstream, like what Travis does. It seems that it is working in public repos, but not in private.


I haven’t tested it with public repos but I’m definitely experiencing that behaviour on private ones. It’d be good to get some clarification on what the actual behavior is. 

Same problem, tested with multiple repositories private and public, the actions are never triggered when the PR is coming from a fork


Same issue,hope someone could help

1 Like

Glad others are experiencing this. It’d be really good to get some clarification from Github.

1 Like

Started a thread with Github folks, referencing this thread. 


Thanks, keep me posted @jiria 

1 Like

Hi @jiria Is there any update ? 

No response yet. I double checked the ticket, turns out my email response was not recorded. So I have responded directly through the webform. I will report back here as soon as I hear back from Github support.

Currently we do not support running PRs from forks for private repos as we are trying to figure out some of the security issues associated with that.  This is something we are looking to address by GA.


Dear @chrispat  ,  Thank you for your response.

For Open Source Projects,  Currently lot of actions  such as coverallslabeller, unit tests, doesn’t work and fails with  *Resource Not Accessible by Integration*  error, for the Pr coming from Forked repos. This is because The permissions for the GITHUB_TOKEN in forked repositories is read-only for all the events. As we are getting more than 90 %  of the contributions from the Forked Repositories, I’d like to use the above mentioned actions for showing up code coverage, labeller, unit tests  in the Pull_request_comment. I think If there is a way to trigger the workflow in the upstream branch for this use-case, then This problem can be solved, or there should be read/write access at least for the Pull Request (access by forked repositories) as this is not critical and won’t have write access to the content of the base repository.  

As I already mentioned, since we get contributions only from the forked repos, this is a must have feature. Others have already reported in multiple other discussions and please tell us if there is any workaround solution to enable action commenting on the PR  coming from the forked repositories. 

Thanks in Advance. 


“Looking to address by GA”

What is GA in this context?

Thanks for keeping us updated- we are also unable to make use of Actions on our corporate repos until this is resolved.

1 Like


Currently we do not support running PRs from forks for private repos as we are trying to figure out some of the security issues associated with that.  This is something we are looking to address by GA.

This is the case for public repositories too right? Forks only have a RO  access token hence merging of PRs or addition/removal of labels cannot be automated. However, according to Github documentation, pull_request events are triggered for the base repo ONLY and hence this workflow could theoretically be automated. So was this change to block events to base repository intended? If so can this be regarded as a  temporary change until a proper security solution is found?


GA = General Availability


What about running PR from fork/branchA to fork/branchB? Original repo is not touched in this case. Fork is public. Is it bug or somehow affected by security reasons?

@chrispat with General Availability fast approaching, I was wondering how sorting out the security issues for private repos was progressing.

1 Like

Unfortuately we were not able to addres the private repo and private fork scneario.  It is something we still do plan to address but I do not have a delivery date at the moment.

@chrispat Thank you for the update. Were you able to address this critical issue for PR coming from the forked repo with a security model in place ??.. 

1 Like

We have work going on to enable that scneario but the changes where deeper than just the actions token for a number of reasons.  I expect we will ship that before the end of the year.