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

231–240 of 301 posts

Re: We built the fastest CI and it failed

#231

Post by smaudet »

jnwatson wrote: post #73
alexvitkov wrote: post #4

What does fast CI even mean? CI is an overgrown shell script running your build and telling you when it fails. In general build tooling has gotten so slow that the cost of whatever CI runner relative to it should be nil. If you want fast CI you need fast tsc, clang, rustc, etc... not a faster program that calls exec on them. A bit more on topic, if you're selling CI and your business fails it's because people you're…

The only part of the Earthly pitch that resonated with me was the ability to run the CI locally. When debugging your CI, it is just faster to find problems when you can run on your own box. I have a gnarly GitHub Actions script that took forever to get right because the debug cycle was 10 minutes long.

Yeah, the faster but is also a bit of a non-seller, they have to integrate the world/deal with bad build times that can't easily be parallelized (what if there are no modular dependencies, that your tool can understand?) except by tools that have nothing to do with their product.

But there have been many times when debugging a CI has been necessary, having to figure out what has gone wrong on a remote system is often an issue...ofc often the remote system is itself the problem...

Re: We built the fastest CI and it failed

#232

Post by BoorishBears »

smaudet wrote: post #225
BoorishBears wrote: post #219

Earlier quoted context omitted.

It sounds like you're unaware of why SSO is considered a security feature at all them, but it's covered right on the site: https://sso.tax/ It's to allow centralized access management. Stuff like firing someone and revoking their access from one platform instantly, instead running around and changing permissions in every tool manually. Or ensuring people in department A can't be invited to some platform for people in…

> It sounds like you're unaware of why SSO is considered a security feature Technically it's an anti feature... The "feature" you are talking about is really identity management not sign on (which, btw, users have different identites, outside of the scope of a single company). At its core it's just a delete function for a username. Putting that in a script with http access should be enough (and not put behind a ridic…

You're barking up the wrong tree: I communicated how SSO's value prop is defined by essentially the entire SaaS industry... if you have a problem with that value prop, Okta alone is 13B worth of short potential for you once everyone realizes they could just use a script with http access.

Re: We built the fastest CI and it failed

#233

Post by smaudet »

IshKebab wrote: post #205
duped wrote: 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…

It is a solved problem - you need to use a build system with sandboxing like Bazel, and also vendor all your tools. Almost nobody does that because very few people realise it is the solution and even fewer realise they're going to need that before they set up their build system.

Switching to a build system like Bazel can be a significant cost, though.

There's no easy solution to making your builds go faster, if they aren't already. There's hardwork and artifact management (dependency hell).

Unless you are asserting Bazel is a direct competitor to Earthly, I don't think the assertion is useful at all.

Re: We built the fastest CI and it failed

#234

Post by gavmor »

AlphaWeaver wrote: post #176
_whiteCaps_ wrote: post #139

> Imagine you live in a world where no part of the build has to repeat unless the changes actually impacted it. A world in which all builds happened with automatic parallelism. A world in which you could reproduce very reliably any part of the build on your laptop. That sounds similar to https://concourse-ci.org/ I quite like it, but it never seemed to gain traction outside of Cloud Foundry.

We spent some time evaluating this on my team, and we're still experimenting with it. I like it a lot, but the project appears to be mostly unmaintained since mid-2021, when the creator left it to work on a lispy CI/CD tool [0] that feels very complicated... not sure what's going on there. [0]: https://github.com/vito/bass

I enjoyed working with concourse as the foundations of Pivotal's release engineering systems. We tried several other platforms, but ultimately concourse was tailor-made for Pivotal-style dev/ops ie highly technical, prioritizing version-control and CLIs over GUIs, with the wall-mounted "build monitor" as a first-class user. While Concourse wasn't explicitly a Pivotal product, shouldn't Conway's Law encourage us not to understate the influences of the Pivotal milieu?

I don't doubt that VMware failed to nurture Concourse's maintenance post-acquisition. I hesitate to make sweeping statements about the legendary virtualization behemoth, but I personally doubt their commitment XP dev/ops culture.

Edit: don't take my word for it, read someone more closely involved to this day, Nat Bennett https://www.simplermachines.com/some-facts-about-concourse/

Re: We built the fastest CI and it failed

#235

Post by stavros »

gabereiser wrote: post #104
chrisweekly wrote: post #101

Earlier quoted context omitted.

(mods: please forgive the off-topic personal question here) Hi Spivak, You're not Lee Spivak (formerly of Upromise in the early 2000's), are you?

This is why some people don’t leave the house.

They're too happy to have their username recognized by strangers on internet forums?

Re: We built the fastest CI and it failed

#236

Post by stavros »

verdverm wrote: post #164
jordemort wrote: post #46

I'm glad that they're just shutting down the service and not closing up shop entirely. I really like the tool (to the point that I regularly stop by their careers page); the syntax for an Earthfile is a very sensible and incremental evolution of Dockerfile syntax, and it makes a whole bunch of things easy that were either previously impossible or very awkward with a Dockerfile alone. I remember when Docker introduced…

Try Dagger, it's better than Earthly I'm a happy user, not paying them yet

In what way? Last I tried both, I could only make Earthly work (though now I'm a fan of CUE because of Dagger).

Re: We built the fastest CI and it failed

#237

Post by mavelikara »

gabereiser wrote: post #158
justin_oaks wrote: post #145

Earlier quoted context omitted.

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"

If you have more than 5 employees, I’m sending you a sales rep to sell SSO to you.

I am going to the competitor. I am paying for the software, but I don’t want your “enterprise tier”, which is really designed for 1000+ employee companies.

BTW, I did just this this morning. The AE came back to offer the enterprise package for the price of the mid-tier package.

Re: We built the fastest CI and it failed

#238

Post by gabereiser »

caloique wrote: post #199
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.

Co-founder of BoxyHQ here - We've crafted an open-source enterprise SSO because we firmly believe that robust security shouldn't be a privilege limited to large organizations. Ideally, essential enterprise-level features like this should become commonplace for all. While we acknowledge the reasons behind SSO being in the enterprise tier, we're all on a collective journey to enhance our security measures. Open Core mo…

Well stated. I was merely showing how one could implement an open core strategy. I’m a firm believer in SSO for all (and not limited to social platforms or GitHub).

Re: We built the fastest CI and it failed

#239

Post by Tokumei-no-hito »

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.

I mean sure but not knowing the difference between git and GitHub is pretty egregious for any senior.

Re: We built the fastest CI and it failed

#240

Post by gabereiser »

maratc wrote: post #149
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.

It’s the one true daemon of the enterprise. Unholy. Can’t die. You’ll find it in the darkest places. But it does it’s masters bidding.
Post reply on HN