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

21–30 of 301 posts

Re: We built the fastest CI and it failed

#21

Post by hardwaregeek »

At least for me, whenever I have to set up CI or touch CI, it's incredibly painful. I usually end up having to push a bunch of commits to debug stuff, and there's a lot of configuration hell. I don't know if Earthly solves this, perhaps it does. But if I were considering moving onto a new CI, I'd immediately think about having to redo this painful process. And that's at the team level. At the org level, switching CI would be even worse.

That does make me wonder, how much of CI adoption is actually moving from one provider to another versus new projects adopting CI for the first time? I'd guess that barring a really extreme reason, most projects pick a CI provider and stick with it.

Re: We built the fastest CI and it failed

#22

Post by deepspace »

adamgordonbell wrote: post #2

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

That line caught my attention too, and it looked superficially true. I have certainly never purchased a tool based on a phone call from a vendor. However, that only pertains to cold-calling, which is the absolute worst way to sell anything.

Advertising is a trillion dollar market for a reason – it works. The trick is to find the correct message and media for the audience.

Effective advertising takes a lot of skill, a lot of money, or both. A large portion of HN posts (including this one) are contain "hidden" advertising, and they absolutely work.

I have purchased more than one developer tool based on reddit and HN reviews, which originated as posts by the seller. On the "lot of money" side, a poster in the arrivals tunnel at SFO is an excellent way of raising brand awareness; even for developer tools.

Re: We built the fastest CI and it failed

#24

Post by mrweasel »

hardwaregeek wrote: post #21

At least for me, whenever I have to set up CI or touch CI, it's incredibly painful. I usually end up having to push a bunch of commits to debug stuff, and there's a lot of configuration hell. I don't know if Earthly solves this, perhaps it does. But if I were considering moving onto a new CI, I'd immediately think about having to redo this painful process. And that's at the team level. At the org level, switching CI…

CI systems are important to me, but my requirement is pretty much: Can it run a bash script. Every CI I've ever used has degraded into a bash script runner. It starts out well enough, you try to use all the build in features but at some point you fallback to running a shells script and then slowly more and more move to the script, because it's easier.

Someone should just build a bash CI, something that can manage secrets and then run one or more shells scripts.

Re: We built the fastest CI and it failed

#25

Post by bluGill »

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

> If you want fast CI you need fast tsc, clang, rustc, etc... not a faster program that calls exec on them Yes and no. Caching stuff and knowing when to run tsc/clang/rustc also improves performance.

Sure, but you have to be 100% perfect in guessing when the cache file must be rebuilt. If there is any situation at all where you use the cached file when you should have rebuilt your tool is not useful.

Note that you can go too far. If you rebuild a file on linux even though the only changes were in a "#ifdef freebsd" (windows, mac...) section that is a waste of time, but not harmful. However we already have tools that do that.

Re: We built the fastest CI and it failed

#26

Post by no_wizard »

prpl wrote: post #14
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…

Enterprise is moving to bazel or similar, often with build caches, and using partial builds on checkin based on what’s changed.

really depends on the enterprise.

I know of quite a few that have buyers remorse over Bazel because they ended up having to have dedicated engineers to keep it working.

There's alot of room for easier to manage Bazel alternatives and I believe enterprises are willing to pay for them.

Re: We built the fastest CI and it failed

#27

Post by falcor84 »

trumbitta2 wrote: post #18

Stopped at "Imagine you live in a world where no part of the build has to repeat unless the changes actually impacted it." because I'm already in that world by using Nx and Nx Cloud.

I've never heard of Nx before, but what you describe sounds like nix, and I'm confused by the name similarity, as based on their site there appears to be no relation.

Re: We built the fastest CI and it failed

#28

Post by bluGill »

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.

Re: We built the fastest CI and it failed

#29

Post by dpeckett »

Part of the issue is that the Earthly is pretty much a CI system in itself. Given that the value proposition of a hosted CI product based on it is pretty minimal. It really is a radical mindset shift and I can see why converting legacy organizations is such an uphill battle.

Re: We built the fastest CI and it failed

#30

Post by habitue »

falcor84 wrote: post #27
trumbitta2 wrote: post #18

Stopped at "Imagine you live in a world where no part of the build has to repeat unless the changes actually impacted it." because I'm already in that world by using Nx and Nx Cloud.

I've never heard of Nx before, but what you describe sounds like nix, and I'm confused by the name similarity, as based on their site there appears to be no relation.

Nx came from the angular ecosystem, where "ng" is short for "angular". So there's no relation to nix, it's just coincidence

(I use Nx at work and nix at home, and both are great in their respective domains.)

Post reply on HN