Hacker News Reader

Comment by AdamMeghji | Hacker News Reader

Congrats on the launch! I've spent some time recently with great success speeding up CI for my teams via alternate actions runners, and the increase in efficiency that comes with dramatic reductions in build times is worth it. When the cost is the same (or less), it's an absolute no-brainer.

How do you differentiate from BuildJet, which takes a similar approach?

View on HN

We've had a few customers migrate over from BuildJet because WarpBuild is in active development. For instance, we are adding support for macos runners in Jan.

Our mission is broader than just fast runners - it's about better CI dev ex. This includes surfacing recommendations that would optimize build times, insights into the critical paths of workflows and more.

We're also investing in tooling to overcome issues that currently exist, such as an action to ssh into running workflows for easy debugging.

Awesome. Do docker image layers persist across build runs? Github, BuildJet, etc. use ephemeral runners, so subsequent runs have to re-pull everything from scratch, which is where most of my actions' time is spent now. If you're able to persist these across runs, that'd be a reason to switch alone.

Not yet, but coming soon (~2 weeks)

This will, by itself, immediately sell me. I’ve spent countless hours and lots of deep deep reading trying to get satisfactory results on GitHub Actions, with no success. From what I’ve seen, plenty of other people are in the same boat.

I'll keep hn posted!

We have this with https://depot.dev out of the box. You connect to a native BuildKit and run your Docker image build on native Intel and Arm CPUs with fast persistent SSD cache orchestrated across builds. It’s immediately there on the next build without having to save/load it over the network.

I migrated from BuildJet this week because BuildJet’s caching is broken. Installing cached pnpm dependencies takes about 12s on GitHub and WarpBuild runners. It takes 2m on BuildJet, which is about half the runtime, effectively negating the cost savings of BuildJet over GitHub.

I reported this issue to BuildJet over a week ago and haven’t received any response.

Thanks for your trust! I'm here to ensure you have a good experience with WarpBuild and for feedback/requests.

I’m currently evaluating Buildjet. I’m curious about this caching issue. Were you using actions/cache or buildjet/cache?

https://buildjet.com/for-github-actions/docs/guides/migratin...

You can continue to use actions/cache if using WarpBuild :)

We used BuildJet cache for months. It’s possible it was always broken and I only noticed a few days ago. I tried both and neither actually cached data. I even tried forking, and upgrading, the BuildJet variant to no avail.

I spent a solid couple hours trying to fix this before moving to WarpBuild.

Exactly my experience as well: https://x.com/crohr/status/1732442731715113374

In the tests with my GitHub Action [1] that spawns ephemeral runners for any workflow, I found BuildJet bandwidth speed 10 to 20 times slower than machines at AWS.

[1]: https://github.com/runs-on/action

Reply on news.ycombinator.com