ci-builder

The platform's prebuilt CI toolchain image: docker:27-cli with git, bash, curl, tar, ca-certificates, helm, and cosign baked in.

Why

App/system workflows used container: docker:27-cli and then ran apk add … && curl …helm… in an install tools step on every build. On a cold dind runner an external fetch can stall with no timeout and hang the whole build until the job deadline — the "dind cold-start". This image moves that one-time egress into an image layer, so workflows do zero external network calls in their steps: they container: onto …/plat/ci-builder:<ver> and go straight to clone → build → push.

Per-cluster, per-arch

ci-builder is a system repo carried in every Mitosis seed, so each platform (including germinated daughters) builds its own copy on its own CI. The Dockerfile picks the helm arch from the build node (uname -m), so the image always matches the cluster arch — vxrail (amd64) and Colima (arm64) each get a native image without multi-arch buildx.

Public on purpose: a job-container image must be anonymously pullable, and Forgejo serves public-repo packages over the OCI bearer-token flow with no creds.

Bump

Tag vX.Y.Z → CI builds …/plat/ci-builder:X.Y.Z. Then bump the container: image tag in the app/system workflows (and _app-template) to match.

Provenance (POL-3)

cosign is baked in so app workflows can cosign sign every image they push. It is installed via apk add cosign from the Alpine community repo (dl-cdn) — the same proven-reachable source as git/bash/curl — not FROM gcr.io/projectsigstore/cosign: gcr.io has broken IPv4 egress on the cold-start dind, and since ci-builder is the FOUNDATIONAL image every germination builds first, a gcr.io dependency would fail that build and break germination for every platform. Bumping to a version that adds/changes cosign means tagging v0.2.0 and updating the container: refs in _app-template (preview + release) to plat/ci-builder:0.2.0.