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
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.
2 comments
[ 4.2 ms ] story [ 16.7 ms ] threadI 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