https://github.com/philips-labs/terraform-aws-github-runner
This works extremely well. It just spins up spot (or normal) instances as needed.
Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds
71–80 of 89 posts
Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds
#72Just out of curiosity, are there any of these 3rd party github action runner services that support persistent disks or have some kind of very fast local cache that can be shared across runners? The majority of time in my workflows is spent downloading the same docker images and dependencies to the runner over and over. I've found Github's own cache to be fairly slow and lackluster.
Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds
#73Earlier quoted context omitted.
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…
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.
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.
Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds
#74Just out of curiosity, are there any of these 3rd party github action runner services that support persistent disks or have some kind of very fast local cache that can be shared across runners? The majority of time in my workflows is spent downloading the same docker images and dependencies to the runner over and over. I've found Github's own cache to be fairly slow and lackluster.
We have persistent disks support in https://dime.run
Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds
#75Just out of curiosity, are there any of these 3rd party github action runner services that support persistent disks or have some kind of very fast local cache that can be shared across runners? The majority of time in my workflows is spent downloading the same docker images and dependencies to the runner over and over. I've found Github's own cache to be fairly slow and lackluster.
We have persistent disks support in https://dime.run
Awesome, just signed up for your waitlist :)
Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds
#76Are you having any slowdown right now? I have been waiting for a 32x to pick up a job for some time now: Requested labels: warp-ubuntu-latest-x64-32x Job defined at: .../workflows/ci.yml@refs/pull/294/merge Waiting for a runner to pick up this job...
We do only 2x, 4x, 16x right now. We can add 32x but generally haven't seen much demand for it.
Ideally it should not be advertised then e.g. https://www.warpbuild.com/pricing
Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds
#77Main CI pain point is all the CIs have some kinda crappyness to them and you are wedded with all the yaml config that is not portable.
ArgoCD might be the way to go (run in Kubernetes) since at least it is hackable if it doesn’t do what you need or there is a bug.
Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds
#78Congrats 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?
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.
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...
Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds
#79Earlier quoted context omitted.
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.
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 :)
Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds
#80This looks promising, but it doesn't work on personal accounts. I'm not ready to install it on my organization account just yet. Can I expect complex caching actions like https://github.com/DeterminateSystems/magic-nix-cache to work as quickly as they do on GitHub?
Yes.
Graham is a great guy and I'm working with him to ensure it does.