Found by running a real build after deploying the isolating runner.
The container failed to start with:
crun: create directory `/sys/fs/cgroup/user.slice/user-999.slice/user@999.service/
user.slice/libpod-<id>.scope/container`: No such file or directory
podman defaults to the systemd cgroup manager, which creates a scope under the
user's own systemd session. gitbay-runner is a system service, so there is no
user@999.service slice and the path does not exist. podman warns about exactly
this when run outside a session and falls back on its own; under the service it
does not.
Every podman invocation now passes --cgroup-manager=cgroupfs. The drop-in's
Delegate=yes gives the service its own delegated cgroup subtree, which is what
cgroupfs manages.
TestPodmanUsesCgroupfs pins it, since the failure only appears on a real host
and would otherwise come back silently.
This is the second thing the first real containerised build turned up. The first
was mine: I had deployed the runner without the server, so builds arrived with no
image and used the bare default. With the server deployed, the build correctly
selects localhost/gitbay-ci:1 and fails only on this cgroup issue.
Ref #144