On 2026-08-25 a deploy job ran with an empty IMAGE_TAG, wrote
`image: localhost:5000/gitea-mcp:` into the infra repo and pushed it.
That is invalid YAML, so Flux failed the ENTIRE apps Kustomization --
every app stopped reconciling for about an hour, including three
unrelated deploys queued behind it.
This job's existing check could not catch it. It greps for
`image: <repo>:${IMAGE_TAG}` after the sed, and with IMAGE_TAG empty that
pattern matches the corrupted line itself, so the verification passes
because of the bug rather than despite it.
Asserting the input up front is the fix: an empty tag now fails the job
before anything is written, let alone committed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011PL5XcG68SvQqz3vGVbWbf
Same change as template-go-agent. A template that carries the build LOGIC
manufactures a private fork of it in every generated repo; one that
carries a CALL manufactures nothing. That distinction is what made
infra#241 a nine-repo sprint plus two rediscoveries in the templates.
Invoked as `bash .gitea/build-image.sh` -- files written through the
Gitea API land 0644, and CI that depends on a file mode is a trap for
every repo generated from here.
Rootless buildah in gitea-runner's hardened securityContext (capabilities:
drop [ALL], allowPrivilegeEscalation: false) cannot remap the UID/GID range
newuidmap/newgidmap need on a fresh base-image pull, and the pod has no OCI
runtime at all. buildctl talks to the host's buildkitd over a socket, so the
privileged layer extraction happens on the host and the pod's securityContext
stops being in the picture. Same pattern as mathias/infra's segment-embedder.yml.
A template is the highest-leverage place to fix this: every repo generated from
here inherits its CI, so a buildah-based template does not merely carry the bug,
it manufactures new instances. The failure is latent — warm base-image layers
mask it — so a generated repo builds fine until its first genuinely cold pull,
which is precisely the situation a new repo is in.
Verification is PARTIAL here, and the limit is worth stating rather than
implying a green build. Running the exact command against this repo's real
context reaches step 8 and fails inside the Dockerfile:
RUN templ generate && go build ... -o /out/app ./cmd/__PROJECT_NAME__
error: failed to solve: ... exit code: 1
That failure is the template's own placeholder path, which cannot resolve on the
raw template — the same reason the guard job gates check/build/deploy off here
(is_template detects __MODULE_PATH__ in go.mod). What it does prove is that
buildctl resolved the frontend, the context and the Dockerfile and began
executing stages; every part of the buildctl integration worked, and only the
template's unsubstituted content did not.
template-go-agent's Dockerfile has no placeholder in its build path, so there the
same command produced a complete 6.8MB OCI archive. The first generated repo from
this template is where this one gets its end-to-end proof.
skopeo copy replaces `buildah push` — buildctl has no registry-push equivalent —
and runs twice to preserve the :sha and :latest tags.
template-go-web was seeded from the real `hostexecutor` project and never
parameterized: go.mod hardcoded `module gitea.d-ma.be/mathias/hostexecutor` and
`hostexecutor` appeared throughout (cmd dir, Dockerfile, Taskfile, CI, context
docs). create_project_from_template therefore substituted nothing and returned
a "no placeholders" partial_failure on the zero-config default path.
Replaced the full module path with __MODULE_PATH__ and the bare project name
with __PROJECT_NAME__ (incl. renaming cmd/hostexecutor → cmd/__PROJECT_NAME__),
matching the substitution the tool performs. Also drops the stale gitea.d-ma.be
host (the placeholder resolves to git.d-ma.be/<owner>/<name>).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mathiasandClaude Opus 5