2 Commits
Author SHA1 Message Date
agent 30dabb5056 fix: combine per-arch tags with imagetools, not docker manifest
docker manifest create refuses a source that is itself a manifest list:
  ERROR: ...:<tag>-amd64 is a manifest list
With Docker containerd image store, docker build --platform linux/amd64
produces an OCI index rather than a plain manifest, so BOTH per-arch tags are
lists and the combine fails — after the slow multi-hundred-MB pushes have
already succeeded. The failure mode is nasty: the per-arch tags are published
and the PLAIN tag, the one both Deployments reference, is absent. Hit on
12.11.1-ci6, 2026-08-31.

buildx imagetools create accepts indexes as sources and combines registry-side,
so it works with either image store. Verification switches to imagetools
inspect and now asserts both linux/amd64 and linux/arm64 specifically, rather
than counting two distinct architecture strings.
2026-08-31 14:44:59 +02:00
agent b2d4e02c6f feat: add push-image.sh for publishing the runner image
Publishing this image by hand hit four obstacles in a row, each of which
recurs on every rebuild:

  413 Payload Too Large      gitea.langenoja.se is behind Cloudflare, which
                             caps request bodies below a registry layer
  Docker Hub auth refusal    the bare MagicDNS name was parsed as a Docker Hub
                             NAMESPACE — a registry host is only recognised
                             when it contains a dot or a colon
  insufficient_scope         the PAT needs write:package, not read:package
  wrong-arch pulls           forgejo-runner runs on arm64 and zegit-runner on
                             amd64, neither pins a nodeSelector, and both use
                             this one tag

The image reference must keep the hostname gitea.langenoja.se, because that is
what the cluster pulls. So the script keeps the NAME and changes only the
ROUTE: it pins that hostname to the Istio gateway on the LAN for the duration
of the push. The gateway serves a *.langenoja.se wildcard cert, so TLS
validates normally — no insecure-registries needed.

The pin carries a marker comment, which makes three cases distinguishable: a
leftover from a run that died before its trap fired (reuse, then remove), a
pin the operator added deliberately (never touch), and one pointing somewhere
other than the gateway (refuse to run). Without the marker a leftover pin was
indistinguishable from a deliberate one, so it survived every later run and
had to be reverted by hand. `--unpin` clears a leftover without building, and
the trap covers INT and TERM as well as EXIT.

It also verifies the published manifest really lists two architectures rather
than trusting the push's exit code.
2026-08-20 14:22:56 +02:00