Publish containerd v2.3.x packages

[Eternity022]

Publish containerd v2.3.x packages

Problem

The _pkg-containerd target in docker-bake.hcl still defaults to PKG_REF = release/2.2
(currently containerd v2.2.5). Upstream has since shipped the v2.3 line —
v2.3.0, v2.3.1, v2.3.2 — which is the new annual LTS branch. No v2.3.x containerd.io
packages have been published through docker/packaging yet.

Ask

Please dispatch the release-containerd workflow for the latest patch, v2.3.2, using the
inputs below. Optionally back-fill v2.3.1 / v2.3.0 for users pinning an exact patch.

release-containerd (workflow_dispatch) inputs:

Version	scope	ref	runc_ref	go_version	release	distros
v2.3.2	recommended	v2.3.2	v1.4.3	1.26.4	release	(empty = all)
v2.3.1	optional back-fill	v2.3.1	v1.4.2	1.26.3	release	(empty = all)
v2.3.0	optional back-fill	v2.3.0	v1.4.2	1.26.2	release	(empty = all)

runc_ref and go_version are pulled from the containerd source at each tag
(script/setup/runc-version and .github/workflows/release/Dockerfile); for v2.3.2 they can be
left empty and the workflow will resolve the same values. revision = 1 (default for a tagged
release).

Prerequisite / reference

Companion PR bumping the default ref so nightly + default builds track the 2.3 branch:
#466
(docker-bake.hcl _pkg-containerd: release/2.2 → release/2.3, GO_VERSION 1.25.11 → 1.26.4).

Build evidence — v2.3.2

Local validation that v2.3.2 builds cleanly on this repo (docker buildx bake validate +
rhel8/rhel9/rhel10 smoke build), full results in reports/build-matrix-v2.3.2.md:

Version	Distro	pkg	verify
v2.3.2	rhel8	PASS	PASS
v2.3.2	rhel9	PASS	PASS
v2.3.2	rhel10	PASS	PASS
v2.3.1	rhel9	PASS	PASS (spot-check)
v2.3.0	rhel9	PASS	PASS (spot-check)

All 10 stages GREEN. Built with GO_VERSION=1.26.4 (matches containerd release/2.3).
Produces e.g. containerd.io-2.3.2-1.el{8,9,10}.aarch64.rpm with provenance + SBOM.

Caveat: verified locally on linux/arm64 only (arm64 host); linux/amd64 is covered by
CI's multi-platform build, not exercised in this local matrix.

---

Actual releases are cut by maintainers via release-containerd workflow_dispatch; this issue
tracks the request and provides the exact inputs + build evidence.

[thaJeztah]

FWIW; we deployed packages of containerd v2.3 to the test channel; e.g. https://download.docker.com/linux/ubuntu/dists/noble/pool/test/amd64/

containerd 2.3 had some regressions so we had to wait for patch-releases of containerd (and runc) before making it the default

[Eternity022]

Thanks @thaJeztah — good to know 2.3.x is already staged in the test channel.

Are the blocking regressions tracked anywhere (containerd/runc issue links)? Would be useful to watch for the patch releases that unblock making it the default.

Happy to help validate in the meantime: I can run the test-channel containerd.io on canary nodes in production-like Kubernetes clusters (kubeadm + Cilium, RHEL 8/9) and report back here under real CRI/kubelet load.

On #466 — do you want me to mark it as draft and keep it rebased until you're comfortable flipping the default to release/2.3?

[thaJeztah]

Are the blocking regressions tracked anywhere (containerd/runc issue links)? Would be useful to watch for the patch releases that unblock making it the default.

I think the most notable ones were addressed, but when we did the docker v29.6 release, we chose to postpone bumping the containerd packages as it was too close to the v29.6 release and we usually want to give it some "burn in" time in our CI as well to see if anything falls out from the update (now merged; moby/moby#52427).

Happy to help validate in the meantime: I can run the test-channel containerd.io on canary nodes in production-like Kubernetes clusters (kubeadm + Cilium, RHEL 8/9) and report back here under real CRI/kubelet load.

Testing is always appreciated! So if you have systems to run on, definitely give the packages from the test channel a try. We intentionally put them in the test channel so that people who already needed v2.3 could install them (they're the same builds as otherwise would go to the "stable" channel, we just gated them to only be deployed to the "test" channel).

do you want me to mark it as draft and keep it rebased until you're comfortable flipping the default to release/2.3?

It's fine to keep out of draft; we'll probably move to 2.3 soon, so keeping it "ready for merge" is fine.

I think a Go security release was announced for Tomorrow, so depending on the scope of that security release, it's possible that containerd (and/or Moby) will need to do a release following that.