4 ms·
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 efficie
by AdamMeghji 3y ago
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?
- suryao 3y agoWe'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.
- AdamMeghji 3y agoAwesome. 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.
- suryao 3y agoNot yet, but coming soon (~2 weeks)
- cqqxo4zV46cp 3y agoThis 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.
- suryao 3y agoI'll keep hn posted!
- kylegalbraith 3y agoWe have this with https://depot.dev 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.
- clintonb 3y agoI 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.
- suryao 3y agoThanks for your trust! I'm here to ensure you have a good experience with WarpBuild and for feedback/requests.
- jeanregisser 3y agoI’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/migrating-to-buildjet-cache https://buildjet.com/for-github-actions/docs/guides/migratin...
- suryao 3y agoYou can continue to use actions/cache if using WarpBuild :)
- clintonb 3y agoWe 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.
- crohr 3y agoExactly my experience as well: https://x.com/crohr/status/1732442731715113374 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 https://github.com/runs-on/action