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.

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.