feat(build): build Talos, Harbor, the Velero KubeVirt plugin and the unlisted images for arm64 - #4552

The package pinned linux/amd64 because its assets were amd64 only.
With arm64 profiles it follows PLATFORM like every other image.

The installer is published as one index under every tag. skopeo
cannot assemble an index from the imager's docker archives, so the
archives go into one OCI layout and a small script writes the index
there for skopeo to push. buildx could build it from OCI layout
sources, but the release job builds on the classic docker driver,
which has no such source.

matchbox carries the kernel and initramfs of both arches whatever
PLATFORM is, rather than those of TARGETARCH: the node matchbox runs
on is not the arch of the machines it boots, so a per-arch image would
hand an amd64 machine an arm64 kernel whenever the pod lands on an
arm64 node. The amd64 assets stay at their old paths, and a group
keyed on the arch iPXE reports sends arm64 machines to the arm64 ones.

Signed-off-by: Aleksei Sviridkin <[email protected]>
Assisted-by: LLM

The talos package now builds for every arch in PLATFORM, and the jobs
that build it without setting PLATFORM would pick up arm64 as well:
the PR Talos build, the nightly disk and the release assets. None of
them has a consumer for arm64 output, since e2e boots amd64 and the
release publishes the amd64 assets only, so each one pins amd64 the
way the image builds already do.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

The build notes said the talos package pins linux/amd64, which no
longer holds and would steer an agent into re-adding the pin.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

arm64 users can only take the Talos ISO, disk images, kernel and
initramfs from the Image Factory today, because a release carries the
amd64 ones only. The tag build now builds the assets for both arches
and uploads the arm64 set next to the amd64 one under the same naming.

It also pushes the talos installer image as a two-arch index, because
a node installed from the arm64 assets pulls its installer from that
image. The rest of the build stays amd64.

Signed-off-by: Aleksei Sviridkin <[email protected]>
Assisted-by: LLM

Upstream publishes quay.io/kubevirt/kubevirt-velero-plugin for amd64
only, so on an arm64 cluster the velero server never starts: its
plugin init container fails with "exec format error". Rebuild the
plugin in-tree from the v0.9.0 release tag, cross-compiled on the
build platform, into an image that behaves like upstream's: it copies
the plugin binary into the plugins volume at /target.

The image target stamps the built reference by digest into
values.yaml, and the package joins the root build list so every build
path refreshes that pin. Until the first stamp is committed the
upstream reference stays in place, which the chart test accepts
alongside the digest-pinned in-tree one.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

The image target stamped only `tag`, leaving the committed
`registry: ghcr.io` in place, so a build against the CI registry would
render the public host with a digest that exists only in the build
registry. Stamping the build host into `registry` instead would split
the source registry across two keys, where the nightly mirror's
substring host rewrite cannot reach it and the published tree would
keep pointing at the private registry.

Set `registry: ""` and keep the whole host in `repository`, stamped
by the image target. The upstream chart joins the two keys, so the
rendered image string is unchanged, and the ref now has the same
shape as every other stamped reference the mirror and promotion
already handle.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

flux-plunger, keycloak-operator, kilo and migration-controller have
image targets but were missing from the root build list, which the
build matrix, the main build and release preparation all iterate. No
CI path rebuilt them, so their pins stayed on images pushed by hand
while Dockerfile, patch and base-image changes never shipped, and the
multi-arch pre-release build would find single-arch pins it cannot
replace. migration-controller shipped a bare :latest with no digest.

Add the four packages, and a test that derives the set from the
package Makefiles so a new image target cannot be left out again.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

Upstream publishes the Harbor v2.15 component images for amd64 only,
so every Harbor pod crash-loops with "exec format error" on an arm64
node. The multi-arch build upstream exists on main but is in no
release yet, so the package now rebuilds the pinned v2.15.1 release
itself: the Go components cross-compile on the build platform, the
registry and the Trivy adapter build from the tags upstream's Makefile
pins, the Trivy binary is fetched per architecture against its release
checksum, and the runtime images keep upstream's photon base, users
and entrypoints. The build fails when those registry and Trivy pins,
the swagger generator or the golang and node build images no longer
match upstream's Makefile at the pinned release, so a version bump
cannot pair a new core with an old registry, scanner or toolchain.

The portal compiles to static JS, so it lives in its own Dockerfile
listed as architecture-neutral in the cross-compile check, and takes
the release pin from the main one so both files build the same
commit.

Because values.yaml now pins the images, `make update` pins the chart
release that ships the same Harbor version and fails when its
appVersion differs, instead of pulling the newest chart onto old
images. Renovate stops proposing tag bumps for the rebuild's build
bases, which follow upstream's toolchain for that release.

The committed refs stay on the upstream digests until CI stamps the
rebuilt ones.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

…4-image-builds

Signed-off-by: Aleksei Sviridkin <[email protected]>

…to feat/arm64-image-builds

Signed-off-by: Aleksei Sviridkin <[email protected]>

…/arm64-image-builds

Signed-off-by: Aleksei Sviridkin <[email protected]>

…iarch' into feat/arm64-image-builds

Signed-off-by: Aleksei Sviridkin <[email protected]>

# Conflicts:
#	Makefile

The plugin image is now built in-tree and stamped by digest, so any
assertion on its string only restates the pin and breaks on every
build or bump without testing what the chart does.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

Signed-off-by: Aleksei Sviridkin <[email protected]>

# Conflicts:
#	hack/image-builders-cross-compile.bats

The release build stamps its own rebuild of the plugin over the
upstream ref, so the test matches the repository name alone. It still
fails when the init container is dropped or points at another image.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

The comment above the ownership loop described how both images used to
be dropped. Describe the reason the check matters instead: neither image
has a release tag to fall back on, so a miss would go unnoticed.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

Two of the gaps listed there are handled in the tree now, and each entry
already says whether it is. The heading sentence still claimed all of
them were open.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>