Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We built the fastest CI and it failed

earthly.dev

Post reply on HN
Print view View original

251–260 of 301 posts

Re: We built the fastest CI and it failed

#251

Post by vlovich123 »

oftenwrong wrote: post #241
bastardoperator wrote: post #166

Earlier quoted context omitted.

Exactly. This just reminds me of "works on my computer". Building locally is more advantageous for developing CI workflow, but I want to be as close to prod as possible and doing that on snowflake developer workstations is an exercise in futility.

Earthly makes use of BuildKit, which essentially executes the build steps in containers. It provides more isolation from the CI runner / dev workstation. Instead of having developers manage their own build tools, Earthly makes it easy to have the build definition manage them.

All flakiness I’ve observed in code I’ve written has been dominated by things like “this job isn’t getting enough cpu cycles and the test assertion is too aggressive in such a scenario” or “lack of CPU cycles is triggering a race condition” or “statistical test X isn’t written robustly”. Not sure how containers solve these problems. My point being that this tool solves some problems for some teams and maybe for a lot of teams that struggle with this problem, but hard problems remain and this isn’t a silver bullet for that. You can’t outsource stability of the project-specific test infrastructure which is where most of the cost lies these days I think.

Re: We built the fastest CI and it failed

#252

Post by shykes »

pxc wrote: post #154

I looked briefly at Earthly a while ago for work because I have to write CI integrations for a whole bunch of CI platforms (GitLab, Azure DevOps, Jenkins, and maybe GitHub Actions). I ended up going with a very similar product (i.e., another nice BuildKit frontend with integrations into a bunch of CI systems), Dagger, because the DSL it used for defining pipelines at the time seemed better to me. I ended up deeply re…

> Dagger devs have de facto abandoned that language entirely in favor of churning out SDKs for the most popular programming languages— all imperative, all Turing-complete, and all, imo, bad fits for the space.

Disclaimer: I’m the CEO of Dagger.

You’re right that we offer SDKs for popular languages, which happen to be imperative. But Dagger remains a declarative system, so what you liked about the earlier versions is still there. The trick is that we moved the declarative layer from static CUE configurations to dynamic GraphQL queries. Then we generated client libraries in various languages from the GraphQL schema. So not only can you still declaratively construct your DAG like before, you can do it in whatever language you prefer. You can even run a DAG directly in pure GraphQL: see https://play.dagger.cloud which lets you do this straight from the browser.

A useful analogy is SQL: it’s a declarative language that is commonly combined with another, often imperative, language.

I hope you find this message useful and consider giving Dagger another chance.

Re: We built the fastest CI and it failed

#253

Post by lelanthran »

justin_oaks wrote: post #145
gabereiser wrote: post #114

Earlier quoted context omitted.

plugins, hardware, hosting, support, there's a number of ways to offer a service for an open source project. Open Core models come to mind. Another is not having enterprise SSO as part of the core. Or not having clustering. Something that would make a VP think twice about adopting your open source solution vs using you as a vendor.

I know these are examples, so I don't want to pick on you too much, but I have one nitpick: Reserving SSO for enterprise customers is awful. Please don't do it. See https://sso.tax/ for details but I'll quote this from it "SSO is a core security requirement for any company with more than five employees"

> I know these are examples, so I don't want to pick on you too much, but I have one nitpick: Reserving SSO for enterprise customers is awful. Please don't do it.

SSO is expensive, adding maybe $10/user/month if the team adds in a purchased solution (passing the cost directly onto the client).

If the customer doesn't want to pay for it because they aren't an enterprise, you can't blame the supplier for not supplying it at a lower price than $10/user/month.

Re: We built the fastest CI and it failed

#255

Post by jcparkyn »

no_wizard wrote: post #71
alexvitkov wrote: post #15

Earlier quoted context omitted.

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…

One thing these tools should do automatically is at the end log to the console (or whatever system) what was compiled and what wasn't. This made debugging so much easier for these issues. They're bound to happen, because we're all human and bugs are a thing. Automatically being able to audit the build as step 1 makes this easy to spot

Visual studio does give a fairly detailed explanation of what was compiled each time, in the output>build view.

Re: We built the fastest CI and it failed

#256

Post by AlphaSite »

reactordev wrote: post #56

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 think the main competitor is gitlab and GitHub, it’s very hard to compete with them. It’s not competing with earthly OSS. Personally the reason we haven’t used earthly satellites or CI is because we can’t use them inside the corporate firewalls, nor does it integrate with our existing CI tools super well, e.g. gitlab.

We use it and love it but it’s missing important enterprise features like that and SSO.

Re: We built the fastest CI and it failed

#257

Post by otabdeveloper4 »

marcinzm wrote: post #140
MatthiasPortzel wrote: post #98

Earlier quoted context omitted.

From the post: > Earthly gives you write once, run anywhere build consistency, making it super easy to reproduce CI failures on your local computer.

That doesn't help with non-deterministic failures and I've also yet to see a true "write once, run anywhere" system ever. It may be 99% "write once, run anywhere" but there's always that 1% edge case.

Nix solves all these problems for good. It's a monster of a system, but if you're migrating anyways then might as well migrate to the real deal, not to some fly-by-night half-baked thing that gets you halfway there.

Re: We built the fastest CI and it failed

#258

Post by palata »

skinner927 wrote: post #57

> Write once, run anywhere Except virtual machines of course. Does everyone only build web apps? What tools do systems developers use? You can’t reliably test system integration in a container.

> Does everyone only build web apps?

Unfortunately I think most people do, which is why there is a big bias towards web tech. I don't, and I hate the fact that most people seem to think that web tech solves everything :-).

Re: We built the fastest CI and it failed

#260

Post by pjmlp »

dpeckett wrote: post #86
reactordev wrote: post #56

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…

That is why most developer products have gone back to the timesharing days.
Post reply on HN