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.
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.
I have skimmed through the article but I am unsure of how it is a faster CI.
Also perhaps Depot should at this point have their own git provider too (maybe a partnership with gitea/forejo/similar folks?) to become an all in one github alternative too at this point for some customers too :-)
I feel like Depot can be interesting for some private repositories github actions
Hey, I'm one of Depot's founders - we built our own custom parser for the YAML syntax that translates to Depot CI's orchestration APIs. This API will actually be a public API shortly, which will unlock some interesting use-cases (support for more syntaxes, direct programmability of the orchestrator, etc)
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.
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.
How does this use github syntax? Is it via https://github.com/nektos/act or something similar?
I have skimmed through the article but I am unsure of how it is a faster CI.
Also perhaps Depot should at this point have their own git provider too (maybe a partnership with gitea/forejo/similar folks?) to become an all in one github alternative too at this point for some customers too :-)
I feel like Depot can be interesting for some private repositories github actions
Hey, I'm one of Depot's founders - we built our own custom parser for the YAML syntax that translates to Depot CI's orchestration APIs. This API will actually be a public API shortly, which will unlock some interesting use-cases (support for more syntaxes, direct programmability of the orchestrator, etc)
Github is down again...
Make a github alternative. please, team at depot Lol
Also yes, it would be fascinating to read about the API/use cases so definitely waiting for your blog post about this topic :)