Files
zegit-forgejo-runner/Dockerfile
agent 6b6743113f docs: correct the registry notes in the Dockerfile header
Two things were wrong, and the second actively misled.

The publish instructions described pushing to the Gitea registry by hand.
Publishing now runs on GitHub Actions to ghcr.io, because Cloudflare's
request-body cap returns 413 on a registry layer and our own runners cannot
build images (host mode, all capabilities dropped). The example tag had also
been mangled to "12.11.1-ci".

"Package visibility is PUBLIC, so the runner namespace pulls without a secret"
was false. The Gitea package is private — flux-config's kustomization says so
in as many words — and the runner Deployments have always carried a pull
secret. Reading that line led me to conclude the ghcr package would need no
credential; it does, and forgejo-runner-system now holds
github-registry-credentials for exactly that.

Verified with `docker build --check`: no warnings.
2026-08-20 15:42:26 +02:00

57 lines
2.6 KiB
Docker

# Custom toolchain image for the self-hosted Gitea Actions (Forgejo) runner.
#
# The cluster runs act_runner in *host mode* (docker disabled), so workflow steps
# execute INSIDE this image. The stock forgejo/runner image is minimal and lacks
# node (needed by JS actions: actions/checkout, setup-go, ...), git, make, etc.
# The runner pod is non-root with all caps dropped, so it cannot apt/apk-add at
# runtime -- the tools must be baked in here.
#
# PUBLISHING IS AUTOMATED. Run the "build image" workflow on GitHub with a tag
# (e.g. 12.11.1-ci4); it builds both architectures and pushes to
# ghcr.io/zegit-zoo/zegit-forgejo-runner. ./push-image.sh remains for building
# by hand. README.md explains why the registry moved off Gitea (Cloudflare's
# request-body cap returns 413 on a registry layer) and why the build cannot run
# on our own runners (host mode, all capabilities dropped).
#
# Then in flux-config set the image on BOTH deployment-zegit-runner and
# deployment-forgejo-runner, digest-pinned.
#
# The image is NOT public. Pulls need a registry credential in
# forgejo-runner-system -- github-registry-credentials for ghcr.io. An earlier
# version of this comment claimed the package was public and needed no secret;
# that was wrong for the Gitea registry too, which is private.
FROM code.forgejo.org/forgejo/runner:12.11.1
USER root
# nodejs -> JS actions runtime (actions/checkout, actions/setup-go, ...)
# git -> checkout
# git-daemon -> provides git-http-backend, which Alpine splits OUT of the `git`
# package (git alone ships git-remote-http/https but NOT the CGI
# backend). Without it, internal/forgeprobe's smart-HTTP tests died
# with "fork/exec git-http-backend: no such file or directory" and
# reported three FAILURES for a missing tool — which turned Gitea CI
# red on every zegit master commit while GitHub stayed green, for
# hours, unnoticed.
# bash -> `shell: bash` steps and many action entrypoints
# coreutils-> GNU userland (alpine busybox tools trip up some scripts)
# curl,tar -> setup-go / gitleaks download + extract their own arch-specific binaries
# make -> zegit Makefile targets
# ca-certificates -> trusted roots for HTTPS to gitea/github/goproxy
#
# Go is intentionally NOT baked in: actions/setup-go fetches the pinned version
# per-run (node + tar are present), so the image needs no rebuild on Go bumps.
RUN apk add --no-cache \
nodejs \
git \
git-daemon \
bash \
coreutils \
curl \
tar \
make \
ca-certificates
# Match the runner pod's runAsUser (1000); keep the image non-root by default.
USER 1000