Comment by pointlessone
4 days ago
I can’t say I like OP’s vision. My main objection is that this vision is terminally online. I want to be able to run the whole build locally (for when my internet is down, or I’m on a plane, or on a remote island in a cave, etc.). The local build and CI should only differ in that local build is triggered manually and results are reported in the terminal (or IDE) and CI build is triggered by a push and reported on the PR (or other web page, or API endpoint, etc. ). It should be the same but for the entry and exit. Tasks, queues, DAGs, etc. it’s all nice but ultimately are implementation details. Even make has DAGs, tasks, and parallel execution. Unless the build can run locally it’s as if there’s no build. Differences between local build and CI, be it because of environment, tasks setup, caching, whatever makes CI painful. It’s precisely because you have a build system for local builds and a separate CI setup that the world contains 10% more misery than it should.
So basically either the whole CI pipeline is just a single command invoking my build system or the CI pipeline can be ran locally. Any other arrangement is self-inflicted suffering.
I want my CI system to track build numbers. When I build locally I don't care about build numbers 99% of the time. There are a number of other things my CI does that I should be able to do locally, but realistically I don't care and so I want to do something different.
I think you have perfectly described OP's vision. A unification of build systems and CI pipelines.
Except the example of a system OP praises can not be ran locally. Well, it can but it’s a full on docker compose setup with half a dozen microservices.