🔥Let’s Do DevOps: Passing data between GitHub Actions jobs, steps, and tasks (and make Matrices dynamic!)

This blog series focuses on presenting complex DevOps projects as simple and approachable via plain language and lots of pictures. You can do it!

Hey all!

I recently published a series of articles focused on how to build a GitHub App that triggers on Org actions, like creating a new repo, how to use an AWS Lambda to access secrets and trigger GitHub Actions, and how to pass an input variable to a GitHub Action. But I realize that a lot of those very cool widgets don’t work without something that’s quite basic — passing information around inside a GitHub Action.

When a variable is set by a task (the smallest unit of work inside a GitHub Action), that variable is accessible within the same task. But the next task? Nope. It’s totally gone. So passing that var to the next step, or another job that’s potentially run on an entirely different builder? Definitely no (at least by default).

However, as you build GitHub Actions, you need to do all of this (and more). Let’s talk what GitHub recommends, and the hacky, awesome ways I personally use that works best for my Actions.

GitHub Actions: Sections

In the intro I used a lot of jargon that might not be familiar to you — Action, Job, Step, Task. Or maybe even Variable. If you know all those terms, skip to the next section! If you want to make sure you understand them, read on.

A GitHub Action is a workflow definition. It’s a yaml-encoded file that lives within the same Repo where the work is done. The logic in these files are very flexible (if a little unintuitive, especially around passing information). The Actions define all the logic that Action will use when it runs. It looks like this. You can see it defines a name for the job (line 1), a list of triggers when the job should run (line 2), and a list of jobs (line 3). Everything else is part of Job or Step syntax, that’ll talk about next.