Triggering a new workflow from another workflow

Now this took me quite some time to figure out. Even with a custom token I was not able to get this working. Now here’s the thing: You need to disable credential caching in the checkout step or it will not use your custom token in a subsequent push step.

      - name: Checkout code
        uses: actions/checkout@v1
          persist-credentials: false
          fetch-depth: 0

@eine a user need write access to a repository to issue a repository_dispatch event. Cross repo triggering is something we have on our backlog to address, however, at the moment we simply do not have a security construct that allows us to create tokens with access to an arbitrary set of repositories. GitHub Actions is a per repository rather than a per organization app, so the token we create for each job only has r/w for the repository the workflow lives in.

1 Like

Any update on this?

I have one workflow creating commits and a tag, and need a second workflow to trigger on the tag even though the commits+tag were performed using GITHUB_TOKEN.

This is a blocker.

1 Like

We need this too.

Use case:

  • When a PR merges, we have a CI workflow that deploys that newly merged code out to our staging server. That deployment takes a few minutes.
  • Once that new code is deplyed, I want to kick off another workflow that will run a short suite of E2E tests against that staging server.

Right now we can’t initiate that E2E test suite because we can’t kick off this testing workflow after the deployment workflow succeeds.

Please bump this up the request queue to get this sort of functionality implemented.

Our team needs this as well so that bot-created PRs can trigger tests to run.

The temporary fix of creating a bot account and using a personal access token is functionally fine, but is less secure. secrets.GITHUB_TOKEN is ephemeral while a personal access token is not. If a malicious user took over an action’s repository, a stolen PAT is generally much worse than a stolen secrets.GITHUB_TOKEN.

1 Like

It also appears that, to trigger workflows via PAT, the user in question must be a Repository Admin? I have created a PAT including all scopes for our CI bot user, but that PAT will NOT kick off a workflow (gets a 404 when POSTing to workflows/<id>/dispatches). My personal skeleton key PAT, however, works to kick off the same workflow.

Can anyone chime in on this to confirm whether or not I’m crazy? :upside_down_face:

+1 This feature is very much desired by our project so that we can trigger a “sign” job to cryptographically sign our releases with gpg after our “build” jobs finish publishing a release on each of our target platforms.

Hi, I was going to post the same issue “need of cross-repository event recognizing and triggers.” As mentioned by @chrispat

This is a really great feature to have as you can build more versatile workflows. I hope GitHub team is working on it.
Does anybody else know any other elegant way to achieve the same result. I read “PAT” can be useful but less secure. Thanks in advance. :grin:

@sarumont, I believe that machine/bot account needs to have Write access to the target repo. Admin is not required.

@maltfield, note that this is currently feasible. It can be improved, and that’s what most comments are about. But, if you really need to do it, you can currently create a machine/bot account, a PAT, and use the dispatch feature. For example, in org, workflows in repos ghdl, docker and ghdl-yosys-plugin are cross-triggered.

To be clear, the PAT workaround does not work for my use-case.

@eine Meant to post here, but I figured that out…my bot only had read access. Got everything working now.

Documentation has been updated since we have workflow_run now, but it seems to not work as expected.

1 Like

+1 same problem. I use a rebase bot to auto rebase PR, but the ci workflow can not be trigger after rebase.


I have the same use case (see:

I hope Github makes this happen soon.

+1 for this issue.

I have a workflow for running tests and linting etc.

I then have a second workflow for deploying, I want this workflow to be triggered by the successful completion of the first workflow:

    workflows: ["quality_checks"]
    branches: [develop]
      - completed

The trigger never fires - I expect because of the permissions issues.

I’m not sure how to work around this nicely

1 Like

Another approach (which I’ve just tested and confirmed to work) is:

    - name: Checkout code
      uses: actions/checkout@v2
      # need to use the personal access token (PAT) so that this workflow can trigger other
      # workflows. See
        token: ${{ secrets.GH_PAT }}

Your solution says to “forget that I previously authenticated with a token that will not trigger other workflows”, while mine says to “persist this token that will trigger other workflows”.

Six of one half, dozen of another.


Along similar lines, I was quite surprised to learn that actions/checkout is a lot more flexible than I’d initially realized. From its documentation examples:

Checkout multiple repos (nested)

- name: Checkout
  uses: actions/checkout@v2

- name: Checkout tools repo
  uses: actions/checkout@v2
    repository: my-org/my-tools
    path: my-tools

Checkout multiple repos (private)

- name: Checkout
  uses: actions/checkout@v2
    path: main

- name: Checkout private tools
  uses: actions/checkout@v2
    repository: my-org/my-private-tools
    token: ${{ secrets.GitHub_PAT }} 
    path: my-tools
  • GitHub_PAT is a secret that contains your PAT

:exploding_head: #WHOKNEW?!

+1 I have a use case where I am using semantic-release to bump versions in a couple files, generate a change log, make a release commit and and tag the release commit. I want that tag to trigger my build workflows so I can do fanout builds with the correct versions.

1 Like

+1 To this being something desperately needed. Like others, I’m trying to use an Action that will auto-update my PR branches using Octokit. That works, but the subsequent CI workflows for those PRs don’t run, meaning that the Action is rendered useless since we mandate all PRs are up-to-date (with passing CI checks) before being considered as mergeable.