The step that makes container isolation deployable here, and the one that would have taken CI down if I had deployed the runner without it.
.gitbay/ci.yml declared no image:, so an isolating runner would have run every
job in docker.io/library/debian:stable-slim — no Go, no git, no gpg, no sshd.
The test job asserts those exist before running, on purpose, so every build on
the instance would have failed on the first step. I found this by checking what
the jobs would actually run in before deploying, not after.
deploy/Containerfile.ci is golang:1.27-trixie plus git-lfs, gnupg,
openssh-server/client, ca-certificates, curl and unzip — the suite's asserted
prerequisites, and what the sonar job needs to fetch its scanner. All four jobs
name localhost/gitbay-ci:1.
Built and verified on bay1 already:
go version go1.27.1 linux/amd64
git version 2.47.3
git-lfs/3.6.1
gpg (GnuPG) 2.4.7
sshd-ok
The tag is deliberate rather than :latest, so editing the Containerfile means
bumping the tag in ci.yml and a running branch's image cannot change underneath
it. The Admin page carries the build command.
The image lives on the runner host; there is no registry to push to and none is wanted for a single-runner instance. A second runner host would need it built there too, which the docs say.
Ref #144