A small word that changes the rhythm of a job
For as long as I have been writing Actions workflows I have been carrying a quiet workaround in my head. Want to warm a cache while the build runs? Append & to the shell command, then squint at logs that arrive out of order and pray the job doesn't exit on you. It worked, sort of. It also meant that anything more interesting than "run one thing, then the next thing" lived as folklore, hidden inside run: blocks.
GitHub closed that gap this week. On June 25 the Actions changelog announced that steps inside a job can now run concurrently, marked with a new background keyword and supported by helpers to wait for them and cancel them. Until now, the changelog notes, every step in a workflow ran in sequence, with each step starting only after the previous one completed. That single rule has shaped every workflow I have ever written. It is gone, and the replacement is the kind of feature you don't notice until the day you reach for it and it's there.
What the keywords actually do
There are four pieces, all of them documented in the announcement.
background: true is the entry point. Set it on a step and that step starts running, and the next step starts immediately. It does not block the job.
wait and wait-all are the rendezvous. wait pins on one or more named background steps and pauses until they finish. wait-all is the same idea against every background step still in flight. Either way you get back into a linear flow on your terms.
cancel is the cleanup. It gracefully terminates a background step when you no longer need it, which is the missing piece if you have ever tried to kill a long-running side process from inside a job and ended up shelling out to kill.
parallel is the convenience wrapper. The changelog describes it as taking a group of steps and converting them into background steps with a wait placed after. For the common "fan out, then join" shape, you write one block instead of decorating five steps by hand.
Where this lands in a real workflow
The shape I will reach for first is the one almost every project has. Independent work that has been running sequentially for no good reason: a docs build, a lint pass, a type check, a test suite that doesn't need the docs build to finish. Today those are four steps in a row. Tomorrow they are four background: true steps with a single wait-all before the deploy step. Same job, same artifacts, but the wall-clock falls to the slowest of the four.
The second one is the long-running sidecar. Start a database container or a fake auth server marked background: true, run the integration suite, cancel the sidecar when you are done. The changelog calls this one out specifically and it is the cleanest fix for a pattern that has lived inside hand-rolled docker run -d calls for years.
The third is the quiet one. Upload telemetry, ship a build artifact, or push a metric while the next step in the job keeps moving. None of that work belongs in the critical path, and now it doesn't have to be.
Rough edges worth flagging
The selling point is also the catch: parallel steps interleave their output. The changelog acknowledges this is what the shell & workaround always struggled with, and the new feature is built around it, but if your team relies on grep-friendly serial logs in the Actions UI you will feel the shift. Background steps also push more concurrency through whichever runner the job is on, which is fine on a generous hosted runner and worth measuring on a small self-hosted one before you decorate a hot job.
I would also be careful with side-effects that race. Two background steps that both write to the same path, or both call the same rate-limited API, will fail in ways linear jobs never did. The fix is not exciting (name your outputs, scope your tokens), but it is real, and it shows up the first time someone copy-pastes a step from one job into another and adds background: true without thinking.
What I'm watching next
Two things. First, whether ecosystem actions, the ones you uses: into your job, start declaring themselves safe to background. A background-aware composite action is more useful than a comment on a forum thread. Second, whether anyone wires this into reusable workflows so a whole job can opt a block of steps into a parallel section without rewriting it. Either would turn a clean primitive into the default shape of a CI job rather than a thing you reach for in the moments you remember to.
For now, the win is small and tangible. Go open the slowest job in your repo, find the two steps that never needed to wait on each other, and put a background: true on the earlier one. That is the kind of change you only register in the relief of not context-switching, and after a few of those, the linear job stops feeling like the natural default.
Top comments (0)