[jakubadamw]

I’ve always been annoyed with the sequential character of jobs in GitHub Actions – that it is impossible to run steps in parallel, when applicable, without moving the job’s logic away from the the .yaml constructs into, say, bash scripts. My ideal runtime for a CI workflow should in my view leverage the model of a DAG and the parallelism made plausible by that to the fullest. Depot CI seems to have addressed this quite well – https://depot.dev/docs/ci/how-to-guides/parallel-steps. I migrated a side project to use it now, and it’s working great – I am seeing some great speed-ups.

[kylegalbraith]

Founder of Depot here. Thanks for sharing your experience!

I couldn’t agree more. It’s always felt odd to me that the entire performance of CI is pretty much pushed out of the primitives and requires an immense amount of custom bash scripts and the like. That kind of flexibility isn’t inherently bad. But there should be primitives that are fast by design baked into the system as well.

Parallel steps is one of those things that unlocks a lot when it’s baked into the system.