40

Another frequently-requested feature for Actions is a way to trigger one workflow based on the completion of another workflow. For example, you may want to take the results of a CI workflow and run some further analysis.

The new workflow_run event enables you to trigger a new workflow when one or more workflows are requested or completed. Runs triggered by the workflow_run event always use the default branch for the repository, and have access to a read/write token as well as secrets. As an example, as a maintainer you could set up a workflow that takes the artifacts generated by the pull request workflow, do some analysis, and post comments back to the pull request. This event is also available as a webhook and works all repos.

This is quoted from Github's blog.

Could anybody tell me how to implement the example proposed using the new event workflow_run? The documentation only provide a very simple example:

on:
  workflow_run:
    workflows: ["Run Tests"]
    branches: [main]
    types: 
      - completed
      - requested

I would be very glad if someone can teach me how to achieve the example.

Potherca
  • 13,207
  • 5
  • 76
  • 94
BobAnkh
  • 511
  • 1
  • 4
  • 9
  • Can't answer but basically asked the same question in the GH community at https://github.community/t/workflow-run-not-triggered/144999 – andig Nov 23 '20 at 20:04

1 Answers1

58

To get the example to work (i.e. to have one workflow wait for another to complete) you need two files. Both files live in the .github/workflows folder of a repository.

The first file would be set up as usual. This file will be triggered by whatever event(s) are set in the on section:

---
name: Preflight

on:
  - pull_request
  - push

jobs:
  preflight-job:
    name: Preflight Step
    runs-on: ubuntu-latest
    steps:
      - run: env

The second file states that it should only trigger on the workflow_run event for any workflows with the name Preflight:

---
name: Test

on:
  workflow_run:
    workflows:
      - Preflight
    types:
      - completed

jobs:
  test-job:
    name: Test Step
    runs-on: ubuntu-latest
    steps:
      - run: env

This more-or-less the same as the example from the GitHub Actions manual.

As you can see on the actions page of my example repo, the Preflight workflow will run first. After it has completed, the Test workflow will be triggered:

Screenshot of workflows screen

As you can also see, the branch does not appear for the "Test" workflow.

This is because, (quoting from the manual):

Screenshot of caveat in the manual

This event will only trigger a workflow run if the workflow file is on the default branch.

This means that the "Test" workflow will run on/with the code from the default branch (usually main or master).

There is a workaround for this...

Every actions is run with a set of contexts. The github context holds information about the event that triggered the workflow. This includes the branch that the event was originally triggered from/for: github.event.workflow_run.head_branch.

This can be used to check out the origination branch in the action, using the actions/checkout action provided by GitHub.

To do this, the Yaml would be:

---
name: Test

on:
  workflow_run:
    workflows:
      - Preflight
    types:
      - completed

jobs:
  test-job:
    name: Test Step
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: ${{ github.event.workflow_run.head_branch }}
      - run: git branch
      - run: env
Potherca
  • 13,207
  • 5
  • 76
  • 94
  • 1
    I'm confused by this: in your example it appears you're using `main` which I can guess is your default branch. What if I want to trigger `workflow_run` i.e. "Test" on a PR and have "Test" run on my PR branch? (This is useful in cases where I want to e.g. run tests and then deploy to a preview environment.) – maxcountryman Jan 07 '21 at 23:34
  • @maxcountryman "Preflight" has `on` set to `pull_request`, which means it will be triggered by a PR. As "Test" is dependant on "Preflight", it will also be triggered for that PR... [as you can see here](https://github.com/potherca-blog/github-actions-workflow_run-event/pull/1) – Potherca Jan 09 '21 at 14:36
  • With the Preflight.yml on a branch 'staging', the Preflight workflow will use the 'staging' branch code. What about the test workflow on 'main'? It will use the 'main' branch code? Or will use the 'staging' branch code? – Carlos Fagiani Jr Jan 13 '21 at 15:31
  • 2
    @CarlosFagianiJr **Now** I understand what you and maxcountryman mean I've updated my answer to explain about how the branching works (and how to deal with it). – Potherca Jan 13 '21 at 20:46
  • @maxcountryman I think I misunderstood your comment before, I've updated my answer regarding branches. Does this answer your query regarding branches? – Potherca Jan 13 '21 at 20:47
  • @Potherca, if I have workflows A and B, and want to add another workflow C which should start when both A and B have finished. Is it possible? – Stqs May 20 '21 at 18:03
  • @Stqs I think that would make an excellent [new question](https://stackoverflow.com/questions/ask) to ask... Not that much room to answer details here in the comments. – Potherca May 21 '21 at 07:46
  • @Potherca thanks a lot. About context, is that possible to get the labels of the Pull Request which triggered the "parent" workflow (Preflight) from the "child" workflow (Test)? – Guts Jun 03 '21 at 12:04
  • @Guts I think it might be better to ask your question as a new one. You could link to it from here, so I can take a look at it... – Potherca Jun 04 '21 at 08:54
  • @Potherca where is the documentation for `head_branch` or indeed, any list of the properties generated by the `workflow_run` events? I can't find them documented anywhere – Segfault Sep 15 '21 at 17:01
  • 1
    @Segfault Ah, yes. Welcome to the jungle known as "GitHub Docs"! The docs you are looking for are in the [Webhook events and payloads](https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_run). – Potherca Sep 16 '21 at 09:44
  • To get there you would start at the ["`github` context" section of "Context and expression syntax for GitHub Actions"](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), which links to [the `workflow_run` section of "Events that trigger workflows"](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#workflow_run), which in turn links to [the "workflow_run" section of "Webhook events and payloads"](https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_run) – Potherca Sep 16 '21 at 09:44
  • the example payload in that document doesn't actually have an example of the workflow_run object, and instead it just says that it shares many of the same properties as a "check_suite"... many but not all? which are which? it's a mystery. – Segfault Sep 16 '21 at 12:29
  • There is a comment on the GitHub Docs issue tracker that actually lists them all: https://github.com/github/docs/issues/4612#issuecomment-856182852 – Segfault Sep 16 '21 at 12:35
  • Yeah, I ran like 150 jobs with a lot of logging and dumping whilst figuring out how everything works. – Potherca Sep 16 '21 at 14:08
  • 1
    Do the invoking and the called workflows need to be on the same repo? – pkaramol Apr 21 '22 at 14:49
  • They do not _need_ to be in the same repo, but if they are not, other things come into play (for instance GitHub Reusable Workflows and various permissions/settings). – Potherca Jun 03 '22 at 12:33
  • Why we need git branch after checkout? – pyang Nov 02 '22 at 19:52
  • @pyang If we do not checkout a specific branch, by default, the workflow will run on the default branch (usually `main` or `master`). – Potherca Nov 03 '22 at 11:16
  • @Potherca When creating this workflow for the first time, via a PR? The workflow does not seem to be picked up in the PR, is it expected ? – bric3 Jan 04 '23 at 11:16
  • @Brice without further details that question is impossible to answer... Might be better to open a new queston here on stackoverflow to ask. It could have to do with branches or [workflow approval](https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks) or any number of things... – Potherca Jan 05 '23 at 16:30
  • I came up with the conclusion that workflows triggered by `workflow_run` can only work on the main branch as you mentioned in your answer, so they cannot run in a PR. Regardless thank you for reaching back ! – bric3 Jan 05 '23 at 21:20
  • `workflow_run` is such a disappointing feature. Even with the workaround the workflow doesn't appear on commits/branch, so can't be used for PR checks etc. Seems GH want us merging all jobs into one massive yml file. Wish there was a way to define jobs in separate files! – wilmol Jun 27 '23 at 10:05