11–20 of 301 posts
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 and try selling? Hell no.
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…
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.
In the end I decided that I couldn’t face the complexity of dealing with someone else’s hosted tooling. Luckily in this case.
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…
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…
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.
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 the build system, I'll pass.
> 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.
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…
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.
RUN gradle build
So what's the real value of it? this basically seems like a better "docker build" alternative, giving nicer inter-layer caching. Maybe will save some time on dependencies if they take some time to install and devs were too lazy to set up own workers and used ephemeral runners instead.
[0] https://docs.earthly.dev/basics/part-1-a-simple-earthfile
- migration of the CI configuration -- from existing CI YAML (github/gitlab) to Earthly (Makefile/Dockerfile hybrid)
- migration of the job runners -- from existing CI to a service hosted by Earthly
I would have thought the first thing is the hard thing. Changing the language could take months or even years.
But I don't understand what the blog post was saying. I thought they validated that part? People were able to switch?
But then it wasn't validated at the end? The customers were faced with 2 migrations, not 1?
But now what's happening? You're still keeping the Earthly syntax but abandoning the CI? Isn't that the hard part to migrate to? I'm still confused.