Regression, mine. The committed Dockerfile had drifted from the image actually in service: the running ci3 contained gcc, musl-dev, python3 and py3-yaml; the Dockerfile did not — and I rebuilt ci4 from the Dockerfile. The rollout therefore removed tools zegit's CI depends on.
Proof ci3 had them: its Gitea runs got pastmake credentials-check (which shells out to python3) and failed later at cover-check. The ci4 run fails earlier, at credentials-coverage: need python3.
package
why it must be there
python3, py3-yaml
the repo's own gates are Python — credentials-coverage.sh, validate-admission.sh, feature-lint.sh; credentials-coverage parses manifests with yaml
gcc, musl-dev
cgo, which go test -race in the Makefile test target requires
Verified on the real base image, not assumed: on forgejo/runner:12.11.1, apk add git git-daemon gcc musl-dev python3 py3-yaml yields Python 3.12.14, a working import yaml, gcc 15.2.0, and git-http-backend on the git exec path.
Assumptions & Decisions
Restoring exactly the four packages ci3 had, nothing more.
The deeper cause is that a hand-built image drifts from its Dockerfile silently, and nothing notices until someone rebuilds. Publishing via CI (#2) is what stops that recurring — every future image now comes from the committed file.
ci4 should be treated as broken. After merge this needs a 12.11.1-ci5 dispatch and a flux-config bump.
**Regression, mine.** The committed Dockerfile had drifted from the image actually in service: the running **ci3 contained gcc, musl-dev, python3 and py3-yaml; the Dockerfile did not** — and I rebuilt ci4 from the Dockerfile. The rollout therefore removed tools zegit's CI depends on.
Proof ci3 had them: its Gitea runs got **past** `make credentials-check` (which shells out to python3) and failed later at cover-check. The ci4 run fails earlier, at `credentials-coverage: need python3`.
| package | why it must be there |
|---|---|
| `python3`, `py3-yaml` | the repo's own gates are Python — `credentials-coverage.sh`, `validate-admission.sh`, `feature-lint.sh`; credentials-coverage parses manifests with yaml |
| `gcc`, `musl-dev` | cgo, which `go test -race` in the Makefile test target requires |
**Verified on the real base image**, not assumed: on `forgejo/runner:12.11.1`, `apk add git git-daemon gcc musl-dev python3 py3-yaml` yields Python 3.12.14, a working `import yaml`, gcc 15.2.0, and `git-http-backend` on the git exec path.
## Assumptions & Decisions
- Restoring exactly the four packages ci3 had, nothing more.
- The deeper cause is that a **hand-built image drifts from its Dockerfile silently**, and nothing notices until someone rebuilds. Publishing via CI (#2) is what stops that recurring — every future image now comes from the committed file.
- **ci4 should be treated as broken.** After merge this needs a `12.11.1-ci5` dispatch and a flux-config bump.
REGRESSION, mine. The committed Dockerfile had drifted from the image actually
in service: the running ci3 image contained these four packages, the Dockerfile
did not, and I rebuilt ci4 from the Dockerfile. The rollout therefore removed
tools zegit's CI depends on.
Proof the deployed ci3 had them: its Gitea runs got PAST `make credentials-check`
— which shells out to python3 — and failed later at cover-check. The ci4 run
fails earlier, at `credentials-coverage: need python3`.
What each is for, so the next rebuild does not drop them again:
python3, py3-yaml the repo's own gates are Python — credentials-coverage.sh,
validate-admission.sh and feature-lint.sh all shell out to
it, and credentials-coverage parses manifests with yaml
gcc, musl-dev cgo, which `go test -race` in the Makefile test target
requires: a C compiler plus libc headers (musl on Alpine)
Verified on the real base image rather than assumed — on
code.forgejo.org/forgejo/runner:12.11.1, `apk add git git-daemon gcc musl-dev
python3 py3-yaml` yields Python 3.12.14, a working `import yaml`, gcc 15.2.0,
and git-http-backend on the git exec path.
The deeper lesson is that a hand-built image can drift from its Dockerfile
silently, and nothing notices until someone rebuilds. Publishing via CI (#2)
is what stops that recurring, since every future image comes from the
committed file.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Regression, mine. The committed Dockerfile had drifted from the image actually in service: the running ci3 contained gcc, musl-dev, python3 and py3-yaml; the Dockerfile did not — and I rebuilt ci4 from the Dockerfile. The rollout therefore removed tools zegit's CI depends on.
Proof ci3 had them: its Gitea runs got past
make credentials-check(which shells out to python3) and failed later at cover-check. The ci4 run fails earlier, atcredentials-coverage: need python3.python3,py3-yamlcredentials-coverage.sh,validate-admission.sh,feature-lint.sh; credentials-coverage parses manifests with yamlgcc,musl-devgo test -racein the Makefile test target requiresVerified on the real base image, not assumed: on
forgejo/runner:12.11.1,apk add git git-daemon gcc musl-dev python3 py3-yamlyields Python 3.12.14, a workingimport yaml, gcc 15.2.0, andgit-http-backendon the git exec path.Assumptions & Decisions
12.11.1-ci5dispatch and a flux-config bump.REGRESSION, mine. The committed Dockerfile had drifted from the image actually in service: the running ci3 image contained these four packages, the Dockerfile did not, and I rebuilt ci4 from the Dockerfile. The rollout therefore removed tools zegit's CI depends on. Proof the deployed ci3 had them: its Gitea runs got PAST `make credentials-check` — which shells out to python3 — and failed later at cover-check. The ci4 run fails earlier, at `credentials-coverage: need python3`. What each is for, so the next rebuild does not drop them again: python3, py3-yaml the repo's own gates are Python — credentials-coverage.sh, validate-admission.sh and feature-lint.sh all shell out to it, and credentials-coverage parses manifests with yaml gcc, musl-dev cgo, which `go test -race` in the Makefile test target requires: a C compiler plus libc headers (musl on Alpine) Verified on the real base image rather than assumed — on code.forgejo.org/forgejo/runner:12.11.1, `apk add git git-daemon gcc musl-dev python3 py3-yaml` yields Python 3.12.14, a working `import yaml`, gcc 15.2.0, and git-http-backend on the git exec path. The deeper lesson is that a hand-built image can drift from its Dockerfile silently, and nothing notices until someone rebuilds. Publishing via CI (#2) is what stops that recurring, since every future image comes from the committed file.