chore: bring images up to date by casibbald · Pull Request #63 · liquidmetal-dev/image-builder

casibbald · 2026-02-05T15:45:27Z

Summary

This PR brings image naming, workflows, and references in line with the current Liquid Metal setup: registry detection for forks, ARM (experimental) workflows, explicit architecture suffixes on image names, and the move from weaveworks-liquidmetal to liquidmetal-dev.

Successful builds can be found here:

1. Registry detection (fork-friendly)

Workflows now push to the repository owner's GHCR by default:
- REGISTRY=ghcr.io/${{ vars.REGISTRY_OWNER || github.repository_owner }}
So forks (e.g. microscaler/image-builder) publish to ghcr.io/microscaler/..., and upstream to ghcr.io/liquidmetal-dev/....
Optional repo variable REGISTRY_OWNER overrides the owner (e.g. for a different org).
Applied in: kernel-images.yml, kernel-images-manual.yml, capmvm-kubernetes-manual.yml.

2. Kernel workflows and images

workflow_dispatch added to Build and release kernel images for manual runs.
Kernel image names now include architecture:
- amd64: firecracker-kernel-amd64, firecracker-kernel-bin-amd64, firecracker-kernel-modules-amd64; cloudhypervisor-kernel-amd64, cloudhypervisor-kernel-bin-amd64, cloudhypervisor-kernel-modules-amd64.
- arm64 (experimental): firecracker-kernel-arm64, firecracker-kernel-bin-arm64, firecracker-kernel-modules-arm64.
New kernel 5.2.21 configs and build for Firecracker (x86 + experimental ARM); Cloud Hypervisor keeps 5.12 and 5.15.12.
Firecracker kernel clone URL switched from git:// to https:// for CI.
ARM kernel workflow added: .github/workflows/kernel-images-arm.yml (push on experimental/arm/kernel/**, manual dispatch, QEMU + Buildx for linux/arm64).

3. CAPMVM workflows and images

CAPMVM image names aligned with architecture:
- amd64: capmvm-k8s-ubuntu-{20.04|22.04|24.04}-amd64
- arm64 (experimental): capmvm-k8s-ubuntu-{20.04|22.04|24.04}-arm64
ARM CAPMVM workflow added: .github/workflows/capmvm-kubernetes-arm-manual.yml (manual dispatch, same inputs as x86: k8s version, containerd, Ubuntu version).
Experimental ARM CAPMVM Dockerfile/Makefile aligned with x86: pkgs.k8s.io repo, KUBERNETES_MAJOR_MINOR / KUBERNETES_FULL_VERSION, package version -1.1, and OS_VERSION for Ubuntu choice.

4. References: weaveworks-liquidmetal → liquidmetal-dev

All image and GitHub references updated from weaveworks-liquidmetal to liquidmetal-dev (default REGISTRY, README examples, and links to flintlock, cluster-api-provider-microvm, site, microvm-action-runner).
Makefile default REGISTRY is now ghcr.io/liquidmetal-dev where applicable.

Files changed (22)

Workflows: kernel-images.yml, kernel-images-manual.yml, new kernel-images-arm.yml, capmvm-kubernetes-manual.yml, new capmvm-kubernetes-arm-manual.yml.
Kernel: Makefile (amd64 names), firecracker/base Dockerfile (https), new configs (5.2.21 x86 + ARM, 5.15.12 CH), README.
Experimental ARM: kernel Makefile (arm64 names), firecracker base Dockerfile (https), capmvm Dockerfile + Makefile (pkgs.k8s.io, version args), READMEs; github-action-runner Makefile + README.
CAPMVM: Makefile (amd64 image name), README.
Root README (publishing/registry and REGISTRY_OWNER example).

richardcase

Thanks for this @casibbald . A few comments.

I have previously experimented with a different way to build the images using the kernel configs from FC and CH directly and then adding additional config options on top, i never quite got it working nicely: https://github.com/liquidmetal-dev/mikrolite-images/tree/main/kernel-k8s-fc
But i do think its a better

.github/workflows/kernel-images.yml

richardcase · 2026-02-12T11:52:38Z

capmvm/kubernetes/Makefile

 K8S_FULL_VERSION?=$(K8S_MAJOR_MINOR).14
 UBUNTU_VERSION?=22.04
-IMAGE_NAME?=$(REGISTRY)/capmvm-k8s-ubuntu-$(UBUNTU_VERSION)
+IMAGE_NAME?=$(REGISTRY)/capmvm-k8s-ubuntu-$(UBUNTU_VERSION)-amd64


Do we need the ability to overwrite the amd64? Perhaps via passed in ARCH

Actually i see there is separate Makefile later for arm :)

@richardcase Should we merge the Makefiles?
It was a bit confusing for me with ARM initially. Maybe a single file that handles all architectures?

So arm was experimental; I did not want to merge them initially as I was concerned it could break others' workflows; however, I think a single Makefile might be nicer. Let me know your thoughts.
@richardcase Maybe as a separate PR where we merge them?

Yeah i think a single makefile would be easier ultimately.

richardcase · 2026-02-12T12:04:51Z

kernel/Makefile


-FC_KERNEL_VERSIONS ?= 4.19.215 5.10.77 # If you update this list, please remember to update the matrix in the kernel-images.yml github action!
-CH_KERNEL_VERSIONS ?= 5.12 # If you update this list, please remember to update the matrix in the kernel-images.yml github action!
+FC_KERNEL_VERSIONS ?= 4.19.215 5.2.21 5.10.77 # If you update this list, please remember to update the matrix in the kernel-images.yml github action!


We need to completely rethink these versions now. For firecracker its 5.10 and 6.1 kernels supported now.

I will give 6.1 another stab, I could not get it to crpss build on my M1, but I have an Intel MiniPC to test with.

updated 6.1 to use the following file:
https://github.com/firecracker-microvm/firecracker/blob/main/resources/guest_configs/microvm-kernel-ci-aarch64-6.1.config

and removed 5.2.21 as I now have an intel machine
5.2.21 - was the only version building on my M1

richardcase · 2026-02-12T12:05:09Z

kernel/Makefile

-FC_KERNEL_VERSIONS ?= 4.19.215 5.10.77 # If you update this list, please remember to update the matrix in the kernel-images.yml github action!
-CH_KERNEL_VERSIONS ?= 5.12 # If you update this list, please remember to update the matrix in the kernel-images.yml github action!
+FC_KERNEL_VERSIONS ?= 4.19.215 5.2.21 5.10.77 # If you update this list, please remember to update the matrix in the kernel-images.yml github action!
+CH_KERNEL_VERSIONS ?= 5.12 5.15.12 # If you update this list, please remember to update the matrix in the kernel-images.yml github action!


We should also take a view of the CH kernel versions.

Any known preference for CH versions ?

I don't know off the top of my head. I would need to have a look around. But lets do that as a follow-up.

kernel/README.md

richardcase · 2026-02-12T12:07:05Z

README.md

+Workflows push images to the **repository’s GitHub Container Registry** by default:
+
+- **Upstream** (`liquidmetal-dev/image-builder`): images go to `ghcr.io/liquidmetal-dev/...`
+- **Forks** (e.g. `microscaler/liquidmetal-image-builder`): images go to `ghcr.io/microscaler/...`


Suggested change

- **Forks** (e.g. `microscaler/liquidmetal-image-builder`): images go to `ghcr.io/microscaler/...`

- **Forks** (e.g. `my-fork/liquidmetal-image-builder`): images go to `ghcr.io/my-fork/...`

kernel/firecracker/configs/amd64/linux-x86_64-6.1.102.config

…rnel/CH/CAPMVM naming, liquidmetal-dev)

casibbald mentioned this pull request Feb 6, 2026

Do ARM images properly #57

Open

richardcase requested changes Feb 12, 2026

View reviewed changes

casibbald force-pushed the chore/bring-images-up-to-date branch 4 times, most recently from cc8c877 to e025159 Compare March 13, 2026 13:03

chore: bring images up to date (registry detection, ARM workflows, ke…

9776b00

…rnel/CH/CAPMVM naming, liquidmetal-dev)

casibbald force-pushed the chore/bring-images-up-to-date branch 2 times, most recently from 001064a to 8e592d1 Compare March 13, 2026 14:38

Address issue with kernel modules

4fa0c91

casibbald force-pushed the chore/bring-images-up-to-date branch from 8e592d1 to 4fa0c91 Compare March 13, 2026 14:38

casibbald added 2 commits March 14, 2026 11:00

chore: reorg for arm

6778f60

chore: unify under a single Makfile

eca8b01

	- Forks (e.g. `microscaler/liquidmetal-image-builder`): images go to `ghcr.io/microscaler/...`
	- Forks (e.g. `my-fork/liquidmetal-image-builder`): images go to `ghcr.io/my-fork/...`

Conversation

casibbald commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

1. Registry detection (fork-friendly)

2. Kernel workflows and images

3. CAPMVM workflows and images

4. References: weaveworks-liquidmetal → liquidmetal-dev

Files changed (22)

Uh oh!

richardcase left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

casibbald commented Feb 5, 2026 •

edited

Loading