Live data from Hacker News

Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

warpbuild.com

41–50 of 89 posts

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#41
post #40

When it says "Get 2000 build minutes for free," is that per month?

Yes. And to clarify to ensure no surprises, it's 2000 build minutes of the 2x runner. That's 1000min if on the 4x, and 25min on the 16x. It's twice more minutes if using the arm runners.

May be easier to think of it as an $8 credit. It shows up as such in the dashboard.

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#42
post #36
post #34

Are 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.

Thank you so much for the speedy response in all mediums I tried to reach out, downgraded to 16x for now, checking if it'll work.

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#43
post #5

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?

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.

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#44
post #5

Earlier 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.

Not yet, but coming soon (~2 weeks)

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#45

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?

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.

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#46
post #21
post #13

Congrats on the launch! There do seem to be a number of other entrants in this space: https://github.com/neysofu/awesome-github-actions-runners#li... What makes you stand out from the pack? The VM approach seems very cool - is this unique in the space? Do you have different approaches that provide speedups or security benefits not possible with other third party runner systems? Any benchmarks against competitors? Sep…

VMs are a necessity if you are serious about security and isolation guarantees. I'd hope everyone else also uses it. I haven't run benchmarks but this comment provides a glimpse - https://news.ycombinator.com/item?id=38571518 VM startup speed has many levels to it. Right now, we are doing the inefficient job of having a pool though we have some items in the roadmap to fix this better. In terms of speed up, we are doi…

> VMs are a necessity if you are serious about security and isolation guarantees. I'd hope everyone else also uses it.

How do you ensure that the VMs are clean on every run? Do you boot up a fresh clean install?

How do you make sure your host machines are clean too? What’s the cadence for resetting those host machines up?

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#47
post #46
post #21

Earlier quoted context omitted.

VMs are a necessity if you are serious about security and isolation guarantees. I'd hope everyone else also uses it. I haven't run benchmarks but this comment provides a glimpse - https://news.ycombinator.com/item?id=38571518 VM startup speed has many levels to it. Right now, we are doing the inefficient job of having a pool though we have some items in the roadmap to fix this better. In terms of speed up, we are doi…

> VMs are a necessity if you are serious about security and isolation guarantees. I'd hope everyone else also uses it. How do you ensure that the VMs are clean on every run? Do you boot up a fresh clean install? How do you make sure your host machines are clean too? What’s the cadence for resetting those host machines up?

They are ephemeral VMs and are alive only for the duration of a single job. They are not reused.

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#48
Hi, quick question:

> Runners are assigned to hardware that is ideal for build workloads with [...] high single-core performance

In my kind of projects (C++, Rust, C) the builds are highly parallelizable, so single core performance is generally not what you want, if you can instead get a lot of cores.

The main bottleneck to my own build pipelines on github was how painful it is to use containers, and how "helpful to idiots but not experts" a lot of the github actions docs are (microsofts style, I guess?).

Good luck though!

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#49
post #48

Hi, quick question: > Runners are assigned to hardware that is ideal for build workloads with [...] high single-core performance In my kind of projects (C++, Rust, C) the builds are highly parallelizable, so single core performance is generally not what you want, if you can instead get a lot of cores. The main bottleneck to my own build pipelines on github was how painful it is to use containers, and how "helpful to…

We do have high core options too (up to 16) but not crazy high like with GPUs. You'll probably still see good benefits.

Could you elaborate on the pain points with using containers?

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#50
1. Can you share information about the specific hardware/CPUs used and where you are hosted? 2. Running untrusted workloads is a huge security challenge. Can you share the technology you are using for isolation and how you have approached mitigation of security threats?
Post reply on HN