At least for me, whenever I have to set up CI or touch CI, it's incredibly painful. I usually end up having to push a bunch of commits to debug stuff, and there's a lot of configuration hell. I don't know if Earthly solves this, perhaps it does. But if I were considering moving onto a new CI, I'd immediately think about having to redo this painful process. And that's at the team level. At the org level, switching CI would be even worse.
That does make me wonder, how much of CI adoption is actually moving from one provider to another versus new projects adopting CI for the first time? I'd guess that barring a really extreme reason, most projects pick a CI provider and stick with it.
CI systems are important to me, but my requirement is pretty much: Can it run a bash script. Every CI I've ever used has degraded into a bash script runner. It starts out well enough, you try to use all the build in features but at some point you fallback to running a shells script and then slowly more and more move to the script, because it's easier.
Someone should just build a bash CI, something that can manage secrets and then run one or more shells scripts.
Once you have hooks into source control for commit-based callbacks into CI, everything else need only be shell. Like, if you build a triggers-shell-scripts-off-source-repo-hooks web service, does putting the results in a pretty web server really matter for anyone besides executives who want dashboards dashboards dashboards? I'm already sending script output to text files and our chat system via curl to boring web service APIs.
In a lot of ways that's pretty much what Earthly is, except those bash scripts run inside containers (that you can configure inside Earthly itself) and you pass files/artifacts between steps/containers.
That does make me wonder, how much of CI adoption is actually moving from one provider to another versus new projects adopting CI for the first time? I'd guess that barring a really extreme reason, most projects pick a CI provider and stick with it.