Live data from Hacker News

We built the fastest CI and it failed

earthly.dev

91–100 of 301 posts

Re: We built the fastest CI and it failed

#91

"People will buy a developer tool, but you can’t sell it."

I think HN will eat this up because few of us enjoy being sold to but like most absolute statements it's probably only applicable in specific circumstances. Enterprises sell tons of developer tools and move millions because of demos done well. AWS and Azure are definitely getting on planes and doing demos.

Re: We built the fastest CI and it failed

#92
post #20

It 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…

The space was destined to collapse these two products not because it makes sense conceptually but because their implementations are almost identical and maintaining fewer systems is great. One was always going to eat the other and CI systems are turnkey, hosted, and live close to the code that it will be running.

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

#93

Earlier 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?

Also, which of my 1,000 test suites are flaky, and when did they start being flaky?

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

#94

This 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…

> Azure DevOps is the devil.

Amen to that!

Re: We built the fastest CI and it failed

#95
post #72
post #52

Earlier 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…

> Sure I can (probably) build curl ten times and get ten technically different binaries

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

#96

It 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

In your opinion, regardless I have to set those systems up anyways to use the Earthly system. Jenkins caches by default and has parallel(), actions uses actions/cache, actions is also async so it's parallel by default. Both can use docker and take advantage of dockers caching management and make is a great tool, but again, any build system can use make.

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

#97
post #8

Earlier 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…

Bazel does this.

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

#98

Earlier 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?

From the post:

> 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

#99

This 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…

Yeah, not suggesting feature withholding per se, but a differentiator on why one would buy vs run the OSS build.

Re: We built the fastest CI and it failed

#100
Innovation isn't just about speed; it's about understanding the nuances of user needs and market dynamics. Even the fastest CI can face hurdles if it doesn't align with the broader ecosystem's expectations and requirements.
Post reply on HN