GitHub Actions Day 17: Dependent Jobs

This is day 17 of my GitHub Actions Advent Calendar. If you want to see the whole list of tips as they're published, see the index.

If you've set up a workflow with multiple jobs -- whether that's a matrix-based workflow or you've just defined the jobs individually -- the jobs run independently of each other, in parallel. Usually, that's ideal. Your jobs will run as soon as machines are available to execute them.

But sometimes you want to be able to set up jobs that depend on other jobs. For example, you might have some services that you want to test against. But to save money, you only want to run those services when you're actually running tests. So you might want to have a job that starts your services, a job that runs your tests, and then a job that stops your services.

To specify dependencies between jobs, you can use the needs keyword to indicate what jobs rely on the completion of other jobs.

Now, this may not seem like a very good example -- instead of using separate jobs, we probably could have just made these three steps in a single job. But using jobs allows us to "grow up": we could actually set up our test infrastructure in one job, then run multiple jobs in parallel that run tests against it, then run our clean up job at the end.

This would allow us to run test jobs on multiple platforms -- in parallel -- and bookend those jobs with the setup and teardown jobs. We can do this by defining our setup job, then defining many jobs that depend on it, and then a final job that depends on those. This is often called "fanning out" and "fanning in".

With this workflow, our setup job will run, then we'll use a matrix to run our build and test jobs across Windows, macOS and Linux, and finally we'll shut down those test resources that we started.

You can easily build advanced workflows by specifying the jobs that need each other to specify your workflow's dependency graph.