[HN Gopher] GitHub Linux ARM64 hosted runners now available for ...
___________________________________________________________________
GitHub Linux ARM64 hosted runners now available for free in public
repositories
Author : Aissen
Score : 127 points
Date : 2025-01-16 17:13 UTC (5 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| mlhpdx wrote:
| Nice. I had gone looking for this a week or two ago and was
| surprised it wasn't available to me.
| verdverm wrote:
| This is awesome, I have been dealing with weird errors in GHA for
| years when having to emulate for multi arch builds
| geerlingguy wrote:
| This is excellent news, as it should unblock having precompiled
| packages available for a number of applications for arm64--for
| me, most notably, OpenZFS:
| https://github.com/openzfs/zfs/issues/14511
| sebazzz wrote:
| Was cross compilation not an option?
| 0x457 wrote:
| I'm probably wrong, but I think this kind of cross-
| compilation requires a nested virtualization and GHA hosted
| runners don't support it.
| yjftsjthsd-h wrote:
| Why would it need virtualization at all? The point of
| cross-compiling is that you build binaries for a different
| arch/platform, ex. running gcc as an x86_64 binary on an
| x86_64 host turning C into aarch64 binaries.
| AlotOfReading wrote:
| You can do cross compilation in GitHub actions and testing
| on QEMU is straightforward. I have a repo that builds for
| and tests half a dozen emulated targets.
| Cyph0n wrote:
| GHA can do nested virt via KVM. Here is an action that runs
| a test that boots up a VM running NixOS: https://github.com
| /aksiksi/compose2nix/blob/main/.github/wor...
|
| You can also run QEMU if you want to build for ARM
| (although this announcement makes this unnecessary): https:
| //github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0...
| ncruces wrote:
| They've done for a while.
|
| My OSS Go project runs tests in 18 different
| OS/architecture combinations.
|
| Some native, some using QEMU binfmt (user mode emulation on
| Linux), others launching a VM. In particular, that's how I
| test the BSDs and Solaris.
|
| https://github.com/ncruces/go-sqlite3/wiki/Support-matrix
| CaliforniaKarl wrote:
| This is awesome!!!
|
| I switched from an Intel Mac to an Apple Silicon Mac a few months
| ago, and have been trying to do as much stuff as possible on ARM.
|
| One thing this should do, is make people think more about
| switching their cloud-based workflows to ARM CPUs, which are
| generally less expensive.
| agartner wrote:
| Here's a quick example I put together on how to use these runners
| to accelerate docker builds: https://github.com/gartnera/actions-
| arm64-native-example
| jimmydoe wrote:
| amazing, exactly what I was looking for. thank you
| bhollis wrote:
| We're using Go, so cross-compilation has never been a big problem
| (for producing artifacts). But this'll be great for testing on
| ARM. I'm interested to see the performance of these instances too
| - our experience has been that Amazon's Graviton processors have
| fantastic bang-for-buck vs. Intel/AMD.
| yjftsjthsd-h wrote:
| It may be worth checking the price and performance numbers; it
| _might_ be worth running builds on ARM and cross-compiling your
| x86 binaries (based on https://github.blog/news-
| insights/product-news/arm64-on-gith... claiming 37% cheaper).
| ncruces wrote:
| If you're using Go, you can also run tests with QEMU binfmt on
| Linux.
|
| https://wiki.debian.org/QemuUserEmulation
|
| Many people don't know this, but on a correctly configured
| amd64 Linux box this just works:
|
| $ GOARCH=s930x go test
|
| The test is cross compiled, and then run with QEMU user mode
| emulation.
|
| Configuring this for GitHub Actions is a single dependency:
| docker/setup-qemu-action@v3
|
| Also, if you want to test different OSes, there are a couple of
| actions to accomplish it.
|
| I'll probably be integrating these Linux ARM instances, but
| this workflow should give you an idea of what was already
| possible with the existing runners:
|
| https://github.com/ncruces/go-sqlite3/blob/main/.github/work...
| amacneil wrote:
| For private repos, Github runners are slow and overpriced. We
| switched to buildjet.com runners and have no regrets.
| FooBarWidget wrote:
| Thanks for the recommendation
| suryao wrote:
| For cheaper (for private repos) and faster arm64 runners, check
| out what we're making at WarpBuild.
|
| We also support spinning up self-hosted runners on your
| AWS/gcp/azure in just a couple of clicks.
| yjftsjthsd-h wrote:
| ...cheaper than free?
| suryao wrote:
| Ha,forgot to add for private repos.
| mystified5016 wrote:
| Our CI runners live on a box in the corner of the office and
| their only operating cost is my time.
|
| Paying someone for CI compute seems insane. The load is so
| variable that you never know if your monthly bill will be zero or
| several hundred/thousand dollars. I especially don't want my
| employees to consider that each and every push costs the company
| a nonzero amount of money. CI should be totally free and
| unrestricted. If a new employee has a _really_ bad day and fires
| off a hundred CI runs (as we all have), I don 't want to explain
| to accounting why there's an enormous spike in the bill.
|
| It costs us a couple of my salaried hours a month to maintain our
| on-site infra. Far, _far_ less than our present AWS bill. Most
| months it needs no attention. It just sits there and does its
| job. Hell, it 's even solar powered.
| lbotos wrote:
| Ok.
|
| You could:
|
| - host your own set of static runners on AWS -- which, have a
| fixed monthly cost.
|
| - pay a provider for hosted runners -- most providers bill in
| _CI Minutes_. So you will run out of minutes if jobs run amok,
| not run up your bill.
|
| - Set up auto-scaling runners that ebb and flow based on
| demand. This case is the one that represents the risk you are
| describing of an unexpected bill increase.
|
| 2/3 cases of "paying someone else for CI compute" are just as
| predictable as your solution cost-wise. Yours could be cheaper,
| but the risk of "unexpected bill increase" is not really there.
| floating-io wrote:
| And his solution will still be cheaper.
| 0xcoffee wrote:
| fyi GitHub bill in minutes, and rounds up. So if you use 1
| minute and 1 second, you get billed for 2 minutes. This is
| applied at job level, so it quickly gets out of control if
| you use matrix builds.
|
| https://github.com/orgs/community/discussions/8726
| kylegalbraith wrote:
| This is exciting to see as arm64 is really a growing space, as
| we've seen since first launching our Docker image build
| acceleration [0]. Free for public repos is definitely a strong
| pull if you can live with some of the quirks.
|
| Even with this, building multi-platform Docker images with fast
| persistent caching in GitHub Actions will still be slow in the
| worst case and tedious in the best case.
|
| We've also expanded into GitHub Actions runners, bringing our
| fast caching and faster compute into the actual runner.
|
| We've done some cool things like making caching and disk access
| faster using ramdisks, Ceph, and blob storage [1]. We're offering
| Intel, ARM, and macOS runners at half the cost of what GitHub
| offers to private repos. We're also focused on accelerating even
| more builds outside of the runner. [2]
|
| [0] https://depot.dev/products/container-builds
|
| [1] https://depot.dev/blog/introducing-github-actions-ultra-
| runn...
|
| [2] https://depot.dev/blog/introducing-depot-cache
| eltondegeneres wrote:
| Your landing and product pages don't mention macOS, only the
| pricing page, but the docs make it look like the macOS runners
| are the same price as Github's.
| kylegalbraith wrote:
| Yeah, this is definitely lacking on our pricing page; thank
| you for flagging it.
|
| We charge $0.08/minute for macOS runners [0] which has 8
| CPUs, 24 GB of memory, and 150 GB of disk. They run with M2
| chips, so the closest GitHub-hosted macOS runner is the arm64
| one with 6 CPUs at $0.16/minute [1].
|
| It's also worth mentioning that we charge by the minute but
| track by the second. Whereas GitHub actually rounds up to the
| closest minute. So a 10-second build on Depot is 10 seconds,
| and you don't get charged a minute until you've accumulated a
| minutes worth of build time.
|
| [0] https://depot.dev/docs/github-actions/runner-types#macos-
| run...
|
| [1] https://docs.github.com/en/billing/managing-billing-for-
| your...
| ecnahc515 wrote:
| While this is great, for people claiming they can now built
| multi-arch images without emulation, how are you planning on
| doing so? As far as I know, if you want to build multi-arch
| images on native runners for each platform, you basically need
| to:
|
| * Configure a workflow with 1 job for each arch, each building a
| standalone single-arch image, tagging it with a unique tag, and
| pushing each to your registry
|
| * Configure another job which runs at the completion of the
| previous jobs that creates a combined manifest containing each
| image using `docker manifest create`.
|
| Basically, doing the steps listed in
| https://www.docker.com/blog/multi-arch-build-and-images-the-...
| under "The hard way with docker manifest ".
|
| Does anyone have a better approach, or some reusable
| workflows/GHA that make this process simpler? I know about
| Depot.dev which basically abstracts the runners away and handles
| all of this for you, but I don't see a good way to do this
| yourself without GitHub offering some better abstraction for
| building docker images.
|
| Edit: I just noticed
| https://news.ycombinator.com/item?id=42729529 which has a great
| example of exactly these steps (and I just realized you can just
| push the digests, instead of tags too, which is nice).
| 0xcoffee wrote:
| Is the price cheaper than x64 instances?
|
| For 'large' instances, ARM64 is cheaper:
| https://docs.github.com/en/billing/managing-billing-for-your...
|
| So what about regular instances?
| tonymet wrote:
| this makes distributing Raspberry Pi binaries a bit easier .I was
| running the Github actions runner on my raspi (which works petty
| well)
___________________________________________________________________
(page generated 2025-01-16 23:01 UTC)