We built the fastest CI and it failed
earthly.dev
We built the fastest CI and it failed
1–10 of 301 posts
Re: We built the fastest CI and it failed
#2"People will buy a developer tool, but you can’t sell it."
Re: We built the fastest CI and it failed
#3I have no personal experience with selling a SaaS, but read that AWS mostly sold to startups at first because there were no migration costs yet. Out of curiosity, has the same been attempted with Eathly and, if yes, did that work?
Re: We built the fastest CI and it failed
#4What 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 providing no value - people can run their build scripts fine without you.
Re: We built the fastest CI and it failed
#5> Why pay both the CI vendor and us
Exactly.
Complexity, not speed, is the problem with builds. It makes perfect sense that "another layer of complexity that wraps up all the other layers" was tough to sell.
Re: We built the fastest CI and it failed
#6Is the concept that requiring a demo for developer tools is a negative signal that strange?
CI is also notoriously expensive to migrate, which the author alluded to. The pumpkin spice latte of software engineering is disdain for things like Jira and Jenkins but what keeps them in their seat is all the custom integration work that has to be done.
Re: We built the fastest CI and it failed
#7What 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.
Re: We built the fastest CI and it failed
#8What 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…
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.
Re: We built the fastest CI and it failed
#9What 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…
[deleted]
Re: We built the fastest CI and it failed
#10What 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.
[deleted]