3 ms·
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
by clintonb 3y ago
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.
- 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