Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

warpbuild.com

Post reply on HN
Print view View original

81–89 of 89 posts

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

#81

Post by suryao »

abatilo wrote: post #64

Awesome work! Congratulations on the launch. This reminds me a lot of https://depot.dev I'm not officially affiliated with them at all. But I'm a big fan of their product. It appears that one difference though is that Depot is more focused on just docker builds and y'all are more generalized runners Is that right?

That's true. We have a slightly different focus - CI workloads. However, the goodness of depot.dev comes from buildkit remote builders and remote cache. That'll be natively integrated into our runners in ~2 weeks.

So you'll get that goodness when running CI with zero changes to your actions needed.

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

#82

Post by suryao »

cswilliams wrote: post #72

Just 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 already have a local container cache for speeding up dockerhub pulls.

Automated container layer caching is coming in ~2 weeks.

This will be present transparently so you'll be able to get the goodness with zero changes to your current actions.

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

#83

Post by clintonb »

jeanregisser wrote: post #78
clintonb wrote: post #10

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

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.

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

#84

Post by cswilliams »

suryao wrote: post #82
cswilliams wrote: post #72

Just 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 already have a local container cache for speeding up dockerhub pulls. Automated container layer caching is coming in ~2 weeks. This will be present transparently so you'll be able to get the goodness with zero changes to your current actions.

sounds great, will definitely check it out in the new year!

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

#85

Post by shepherdjerred »

mratsim wrote: post #38
shepherdjerred wrote: post #26

Earlier quoted context omitted.

What do you need macOS for? Have you considered cross-compilation? Zig + Rust allows cross-compilation for Rust: https://actually.fyi/posts/zig-makes-rust-cross-compilation-...

Anything that interact with the kernel needs to be tested on the actual OS. Simiarly if you call native libraries. And Apple Clang masquerading as GCC or not having all upstream LLVM patches is also annoying.

Sure, but now your interaction with macOS is limited to automated testing and not compilation + testing. Depending on the application, this could be worthwhile.

For example, at work, we cross-compile C/C++/Fortran/Rust code in R packages. We compile for supported versions of R, so that ends up being tens of thousands of packages that we need to compile.

By cross-compiling we saved a lot of work and nearly eliminated our need for macOS.

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

#86

Post by shepherdjerred »

suryao wrote: post #39
shepherdjerred wrote: post #26

Earlier quoted context omitted.

What do you need macOS for? Have you considered cross-compilation? Zig + Rust allows cross-compilation for Rust: https://actually.fyi/posts/zig-makes-rust-cross-compilation-...

A very common use case for macos runners is iOS builds.

You can cross-compile iOS apps.

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

#87

Post by crohr »

lionkor wrote: 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…

If you need machines with high number of CPUs, you can check https://github.com/runs-on/action which allows you to select any EC2 instance type as ephemeral runner. Plus it’s the cheapest on the market, open source, and not a SaaS

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

#88

Post by crohr »

clintonb wrote: post #10
AdamMeghji wrote: post #3

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.

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

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

#89

Post by solardev »

yjftsjthsd-h wrote: post #54
solardev wrote: post #8

Earlier quoted context omitted.

A lot of smaller teams/companies don't really care about security, sadly... and is this really that different from Github Actions, CircleCI, Vercel, anything...?

It has the difference of not having been around for as long and accruing reputation. That's nothing inherent, and will come with time of course. Of those, the only other difference is that github actions has the advantage of being first party; if you use github, then there's no increase in security exposure by using their own actions.

That's fair!
Post reply on HN