"People will buy a developer tool, but you can’t sell it."
We built the fastest CI and it failed
91–100 of 301 posts
Re: We built the fastest CI and it failed
#92It was honestly a bit hard for me to understand what happened from this write-up. I read it a few times, and the terms are still bit confusing. Seems like there are at least two separate issues - migration of the CI configuration -- from existing CI YAML (github/gitlab) to Earthly (Makefile/Dockerfile hybrid) - migration of the job runners -- from existing CI to a service hosted by Earthly I would have thought the fi…
It's not about migrating the syntax. It's that people's CI over time become some kind of amalgamated model encapsulating how a firm makes every individual piece of software it makes and lands it places, think (ab)using a CI as Airflow (arbitrary automation job runner), and that the migration is first reverse engineering what people used to know, before even starting untangling all of that to express it some different…
I wish they had either remained separate or gone the other way but it's not worth swimming upstream for it.
Re: We built the fastest CI and it failed
#93Earlier quoted context omitted.
Can you expand on the word "feedback"? What kind of feedback are you looking from CI?
It's one thing to know a build failed, it's another thing to know why and how a build failed, where it failed, and what the cause was. If I have to swim through or context shift to a separate build system's output to get that, what is this actually doing for me?
Flamebox almost got this right, but groups by wall-clock instead of git sha:
https://flamebox.sourceforge.net
The screenshot is most of what there is to see. Clicking a test run opens the test log.
Does anyone know of a currently-maintained alternative with a less-bad dashboard?
Re: We built the fastest CI and it failed
#94This is a good write up of why you shouldn’t give away the house when you open source things. The issue was really this: Earthly being open-source, Earthy Satellite users were already seeing the benefit from 95% of Earthly CI . I’m a huge fan of open source, however, if your business model includes an open source model - you need a differentiator. Beyond blazingly fast(tm). You need a reason for people to offer up th…
Amen to that!
Re: We built the fastest CI and it failed
#95Earlier quoted context omitted.
It's not a solved problem, very few builds in the wild are deterministic and reproducible. You have to build up the universe from scratch (like guix and nix) for the caching to be sound enough to be reliable. Just because an algorithm exists that can help doesn't mean that the universe of software can fit cleanly into a model where that algorithm is perfect. The other fundamental problem with this model is that it ca…
> very few builds in the wild are deterministic and reproducible There's a difference between 'deterministic and reproducible' and 'predictable'. Sure I can (probably) build curl ten times and get ten technically different binaries, but the differences aren't relevant to the functioning of the actual result. Assuming my build environment isn't changing out from underneath me (i.e. if I'm using the same versions of th…
I think assuming the same build environment, then building curl is actually deterministic and reproducible:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable...
(It says reproducibility fails if CFLAGS is different, but I'd count that as a change in build environment?)
Re: We built the fastest CI and it failed
#96It failed because the marketing is outright bunk and overly dishonest. If I compile with Jenkins, Actions or Earthly, that compile time is going to be the same under each build system assuming the same build node. Claiming you're 20x faster when CI is firing within seconds is kind of meaningless. Caching and parallel execution are age old concepts when it comes to CI and every modern build system can do it. CI is all…
> Caching and parallel execution are age old concepts when it comes to CI and every modern build system can do it. It is much harder to set up caching/parallelization with GitHub Actions, Jenkins, Docker, and Make than it is with just Earthly
I don't think it's harder at all, in fact in my mind Earthly is more money, more steps, more time and energy, and more vendor lock in for the same output you can get in just about any modern build system.
Re: We built the fastest CI and it failed
#97Earlier quoted context omitted.
Perusing this article quickly, it means a CI that is automatically handling things like caching build artifacts so that you don't need to recompile your entire repository every single commit. It's not about a faster program to call exec; it's about a program that knows it need not even call exec.
Incremental builds are something even enterprise build systems fail at. I've had Visual Studio and MSBuild fail on me multiple times by deciding not to recompile a certain .cpp file, because they got the dependency graph wrong. This results in a running but inconsistent executable that's a bitch to debug. If you're selling me another tool that duplicates this work, but that has even less context on my project than th…
I have to be honest - MS Build does not scale well. Companies use it because it’s the default.
Re: We built the fastest CI and it failed
#98Earlier quoted context omitted.
Can you expand on the word "feedback"? What kind of feedback are you looking from CI?
It's one thing to know a build failed, it's another thing to know why and how a build failed, where it failed, and what the cause was. If I have to swim through or context shift to a separate build system's output to get that, what is this actually doing for me?
> Earthly gives you write once, run anywhere build consistency, making it super easy to reproduce CI failures on your local computer.
Re: We built the fastest CI and it failed
#99This is a good write up of why you shouldn’t give away the house when you open source things. The issue was really this: Earthly being open-source, Earthy Satellite users were already seeing the benefit from 95% of Earthly CI . I’m a huge fan of open source, however, if your business model includes an open source model - you need a differentiator. Beyond blazingly fast(tm). You need a reason for people to offer up th…
I'm not sure feature withholding has traditionally worked out well in the developer space. The churn rate for tooling is so high that if Earthly were to intentionally cripple their product I'm sure the majority of developers would just move on to other inferior, but free, options (eg. taskfile). Maybe those that remain could be converted successfully but it's quite a gamble. A great turn around story in recent times…