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

141–150 of 301 posts

Re: We built the fastest CI and it failed

#141

Post by pixl97 »

rewmie wrote: post #129
mcnichol wrote: post #105

Not to rain on the parade here but this is literally a copy-pasta product. Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines...and surprise surprise when you look at where he came from...Ex-Google, Ex-VMW, RabbitMQ... If OP wasn't in and around the source of all these tools above then they were at the very least first cousins to the story. The sales cycle is long, integrations require multiple dimensions of ex…

> Not to rain on the parade here but this is literally a copy-pasta product. More to the point, the product offered no compelling reason to use it, let alone pay for it. Being "fast" is not a selling point. Developers don't want slow pipelines, but that does not mean they want fast pipelines. The speed that the pipeline works is more depending on how the pipeline is setup than the overhead of the pipeline service, an…

Reliable, configurable, and compatible. That's what, at least from the work I do, seems to be what the market is looking for.

Most CI/CD for sizeable companies have integrations into other systems, such as static analysis and things lime SBOM. Those tools tend to take a bunch of time outside the CI. They also need to ensure the results from those tools can break builds along with other alerting. Eventually the CI itself becomes a small fraction of total execution time.

Re: We built the fastest CI and it failed

#142

Post by CobsterLock »

pharmakom wrote: post #97
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…

Bazel does this. I have to be honest - MS Build does not scale well. Companies use it because it’s the default.

I don't have a ton of experience in Bazel, but from what I have experienced with Bazel I think it would be more accurate to say that you configure the dependency graph yourself in Bazel. Then Bazel can determine what to build from scratch and what to take from cache

Re: We built the fastest CI and it failed

#143

Post by ilyt »

> Why not just simplify the stack? Why pay both the CI vendor and us, when you can just pay us?

Coz the CI they "pay" for comes with rest of the stack, and is not just CI product. Both Gitlab and Github have far more than just CI

>These weren’t the raving fans we were used to talking with. New people would look at Earthly CI with a skeptical eye. They were mostly thinking that “all CIs are the same - they just have different syntax,” and then they would not really look any further as to why we might actually be different.

we don't care about CI, we just need it and we need it to work.

If we have working CI manifest for our app, the new app will have same manifest with few find-replace in it. The pain might be there to create it. And the example ones don't really look any easier than doing same thing in Gitlab.

Frankly, putting some transpiler that takes Gitlab or Github CI config and just makes Earthfile on the fly would probably convince some people to at least try.

Re: We built the fastest CI and it failed

#144

Post by gabereiser »

WorldMaker wrote: post #137
shandor wrote: post #115

Earlier quoted context omitted.

Is there an actual technical point beyond ”MS bad” for this sentiment? Honestly asking, as I’ve been mostly hearing positive things about AzDO, and from developers of all people.

AzDO is "decent", depending on your needs, but it's in an unfortunate zombie state where Microsoft is supporting it just enough to keep it stable and keep certain enterprises happy and consistently insisting that AzDO has a roadmap and is still beloved, but it is very clear that all of the actual resources are going to the GitHub side of the house in 2023. (One of the most recent signs of this crazy zombie state that…

This. AzDO will die. It will be replaced entirely by Github. It originally was only designed as a way to get people onto Azure using their already-existing MS partnership to give it away for free. The only purpose, drive adoption of Azure Cloud. In runners, resources, stickiness, and preventing abandoning ship.

Re: We built the fastest CI and it failed

#145

Post by justin_oaks »

gabereiser wrote: post #114
staunton wrote: post #111

Earlier quoted context omitted.

What's the difference?

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"

Re: We built the fastest CI and it failed

#146

Post by cyberpunk »

bluGill wrote: post #28
consoomer wrote: post #11

We work in an industry where senior developers don't know the difference between git and Github. The same seniors don't know the difference between Github actions, Travis CI and have never heard of Jenkins. Hardly anyone cares. Are you going to sell this to a startup? I doubt it. Are you going to sell it to a smb or enterprise company? Maybe. Is there a market to make cash there? Sure. Is it what I would want to make…

Why should senior devs know that? Someone needs to know those differences, but on a large enterprise project you have a team that keeps the CI system working. The rest need to know how to checkin a file and how to check the CI output. They shouldn't care about those details. I expect any senior developer CAN learn the above things. However that doesn't mean they are worth knowing.

Just to be clear, your question is: why should a senior developer -- whose job ultimately involves managing a complex set of text files -- understand basic concepts behind the industry standard tooling for managing ... text files?

Complete waste of time, they should be out playing golf with a board member instead, right..

Re: We built the fastest CI and it failed

#147

Post by ilyt »

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…

From my experience hosting our own instance of Gitlab + few CI/CD workers was few weeks of initial work (integrating with company's LDAP etc.) then around one ops-week per year worth of maintenance over last few years (50+ developers, dozens and dozens of projects).

Before that we had just "a git server + jenkins + some slaves" that took even less maintenance (althought I'd imagine more fumbling on dev side with job config)

Earthly isn't cheaper than any of those options and none of our clients use it (and we occasionally have to work on client's gitlab instances).

Re: We built the fastest CI and it failed

#148

Post by hotnfresh »

WorldMaker wrote: post #137
shandor wrote: post #115

Earlier quoted context omitted.

Is there an actual technical point beyond ”MS bad” for this sentiment? Honestly asking, as I’ve been mostly hearing positive things about AzDO, and from developers of all people.

AzDO is "decent", depending on your needs, but it's in an unfortunate zombie state where Microsoft is supporting it just enough to keep it stable and keep certain enterprises happy and consistently insisting that AzDO has a roadmap and is still beloved, but it is very clear that all of the actual resources are going to the GitHub side of the house in 2023. (One of the most recent signs of this crazy zombie state that…

Ugh, they’re busy bringing bad project management to GitHub, in a quest to make it suck as much as all the others.

The old issues + tags + milestones was perfect. Now it’s the same needlessly-heavy thing as all the rest, with their reimagined “projects” thingy.

But then again I’ve not once seen a PM embrace any version of GitHub’s project management, with the only explanation forthcoming being “it’s confusing for non-technical users” (fucking how? More confusing than Jira or Asana? No friggin’ way) so maybe they have to shit it up and make it hard to use and easy to get lost in or miss info in, to get any traction with PMs.

Re: We built the fastest CI and it failed

#149

Post by maratc »

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…

> Swarm’s of Jenkins is what most are used to in the enterprise.

Thanks, I thought we were one of the last places with that setup, nice to know this unholy contraption is actually somewhat standard.

Re: We built the fastest CI and it failed

#150

Post by rhaps0dy »

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"

But it should be OK to reserve SSO for paying customers.
Post reply on HN