Use native GitHub ARM64 runners for Notebook Image Builds

[thesuperzapper]

Background

Right now, we build the example-notebook-servers using QEMU emulation on GitHub actions AMD64 runners. These builds are extremely slow due to emulation, meaning we dont even run them in PR tests (where we should).

However, it seems like ARM64 runners are now available for all open-source github repos:

• https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories
• https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/

NOTE: this is only really needed for the example notebook images, because small go ones are very quick to build under emulation.

Proposal

There is a lot of discussion on https://github.com/orgs/community/discussions/148648 (and other places) on how to approach multi-arch builds with native runners, we should see what people come up with.

It's likely that unless something like what I proposed in https://github.com/orgs/community/discussions/148648#discussioncomment-12229847 gets adopted by GitHub, we would need to build the images on the native runners, and then export them as artifacts in seperate jobs for ARM/X86, then have a final job combine these artifacts using docker buildx imagetools create ... so they can be pushed to the registry under the same tag.

However, this is likely to be very painful for our notebook images, because they all depend on each other in a tree, so we would have a lot of artifacts to deal with.

Also, it would be complex to do the "parallelization" we do right now, where we build the base image first, then have three child jobs that build jupyter, rstudio and code-server by pulling the base (and again run multiple jobs downstream of these for jupyter-pytorch, and jupyter-tensorflow).