Triggering a new workflow from another workflow

Per, workflows cannot trigger other workflow runs when using GITHUB_TOKEN:

An action in a workflow run can’t trigger a new workflow run. For example, if an action pushes code using the repository’s GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.

I’m curious if this is a temporary limitation, and if this will be removed in the future. I can understand the reasoning for it, but it’s limiting for certain types of things that can be automated.

One example is using the deployments API with Actions. I’d like to build one workflow that handles /deploy comments in PR’s to create GitHub Deployments, and then have another workflow that handles them. As of right now, that’s not possible if the workflow that creates the deployment uses GITHUB_TOKEN.

The only way to work around this right now is the either 1) create a bot user and use a personal access token or 2) create a github app. Both of these are cumbersome, and suck for various reasons.



Is there any update on this topic from the GitHub side ? 

Thanks in Advance. 

1 Like

The documented limitation is still in place.  However, as we look at other scenarios specifically around continuous deployment we will likely adjust this behavior for specific scenarios.


I have the same issue while pushing newly formated code. Is there any workaround? Even with Github API?

1 Like

I have the same issue with a use case where a GitHub Action updates a pull request branch using a GITHUB_TOKEN. I would expect the corresponding  push and pull_request.synchronize events to trigger my CI workflow but it’s not the case with today’s limitation.

1 Like

I think I’m running into the same limitation. I have two checks, one (1) which runs ordinary tests on the code (classic CI use case), and the other (2) which is supposed to auto merge PR’s when they have a certain label ( The main branch is protected, the tests need to pass before merging is allowed. What happens is that (2) finishes before (1) so the merge fails, but (2) is not triggered again when check_run/check_suite completes.

1 Like

I’ve fallen back to using a custom auth token (linked to a bot account), which will trigger the checks on commit/push.

would be nice to see this feature.  I’d like to have the logic for creating releases or packages in their own  yaml file, but have that workflow only run if the other workflows have returned succesfully.  I could also see this being ideal for integration tests, or other things that might come before a deployment.

1 Like

I also have a use case for it, where an auto merge action should trigger a deployment, but because of this limitation it doesn’t. Is it planned to be changed before GitHub Universe? It seems like a breaking change, unless it would be hidden behind a flag.


My use case is automatically creating a PR from feature branch to master branch when there is a push to the feature branch.

When a new PR is created, I have a few things I do with it, such as look up the related issue using commit messages; add the PR to a project; add some more details to the PR; etc. However, I can’t do any of that if the PR workflow doesn’t run following the push workflow.

Is there a specific technical reason why the limitation exists? Such as unintended infinite feedback loops of workflows? Because you can probably limit that to some depth using the token – I doubt most of us needing this functionality would need anything more than 3 levels of chaining.

Hi Chris, do you have any news on this? I just bumped into yet another issue that made Coveralls break for me:

I need this as well! Using the repository_dispatch event does not work because this only can be done on master.

1 Like

I agree that this would be a killer feature to have. All my workflows could then adhere to the single-responsibility-principle instead of writing long YAML files with many if statements.


Is this still the case? I’m actually seeing workflows being triggered from commits pushed with GITHUB_TOKEN, which I was hoping it wouldn’t…

Are you using the defeult GITHUB_TOKEN, the one on the name of GitHub Actions, or a custom one?

Any update on this? Trying to get working when all checks have successfully completed and not having any luck. Thanks!

Another use case is automatically creating a new PR on a successful build. I have a workflow that does that when (a) feature branches build successfully (automatic PR against master); (b) master builds successfully (automatic PR against staging); © staging builds successfully (automatic PR against production).

There is a workflow that, when a new PR is created or an existing PR has commits added, it adds a comment for things such as list of authors from commits, which issues the PR closes (by parsing the commit messages), etc. This is a separate workflow from the build workflow, because either (a) a new PR got created automatically as described above; (b) someone may have created a new PR manually.

Please note that for now I am using a Github App and this action that obtains a token for that Github App. Not pretty, but works with some glaring security issues (thankfully I am not a big org).

Joining the party late but I just found this link and it appears that it can be made to work:

Its clearly not ideal though.

I’m running into this issue as well.

I’m running into this issue when trying to:

  • Start a workflow in repo B of an organization after pushing to repo A.
    • Or, trigger a workflow in repo B manually.
  • Start a sequence of workflows in repo A after the first one is triggered externally.

First, I expected the “Webhooks” feature in repo A to work straightaway, since both repos belong to the same organization. However, it fails.

Then, I expected the default GITHUB_TOKEN to allow triggering events across repos of the same organization. It didn’t work.

Hence, I’m using a PAT as a workaround. However, I think this is NOT desirable because it provides a much wider scope than it should be required. As a result, a machine account needs to be used and ad-hoc limited permissions need to be set up. Still, the machine account needs write access to the whole repo. Neither ‘read’ nor ‘triage’ suffice.

Moreover, I’d like to extend the scheme in order to cross-trigger workflows between multiple organizations. Here I’m stuck with how to proceed. @chrispat, which are the minimum permissions that a user needs to have in a repo and which is the most limited PAT that can be created for that user, so that it is possible to trigger a repository_dispatch event?

1 Like