One thing I hate about the current state of affairs is that CIs use a ton of configuration file formats. Every single one wants to lock you in and make it painful to move to something else.
Since all CIs seem to be allowing executing shell scripts one way or another, in theory it is possible to avoid vendor lock in by coding your CI as a shell script which is called from the CI configuration file. This way only the very minimal bootstrapping stuff remains in CI config and the rest remains in your shell scripts that you can port to any CI.
I see this same sentiment comment in every one of these threads, and that reductionist view seems to ignore the things that make CI valuable: conditional stages, caching, passing artifacts from one to another, secret management, etc
If the retort is "well, just implement those things in your shell scripts" then at that point one has reimplemented Earthly in shell which feels objectively worse
:wave: Dagger contributor here. This is exactly one of the many reasons why we've decided to build Dagger. We're working for a future where CI pipelines can be defined in your language of choice and composable across different ecosystems. If you want to know more, happy to chat in our Discord community.
Looking at you Team City. Having to write build configs in Kotlin is better than clicking through a bunch of GUI but they leave a lot to be desired in their API docs. I’ve found that I pretty much have to build the config first in the GUI and then export to Kotlin and tweak by hand due to the lack of documentation for certain things that the GUI handles for you.
