Files
SilverMetal/linux/build/scripts
SysAdmin 4a837e07ed
Some checks failed
Build SilverMetal Linux ISO (reproducibility-gated) / builder-image (push) Successful in 2s
Build SilverMetal Linux ISO (reproducibility-gated) / build-and-verify (push) Failing after 1m17s
fix(linux/build): discover job container ID from cgroup, not hostname (M1.1 iter21)
Run #4268's build-and-verify died <1s into Build A:

    docker: Error response from daemon: No such container: docker

Cause: build.sh's CI path uses `--volumes-from "$(hostname)"` to
inherit the parent job container's /workspace mount, but in the new
runner config (network: host applied via the now-actually-loaded
config.yaml) `hostname` returns the literal string "docker" inside
catthehacker/ubuntu:act-latest — the image bakes that into /etc/hostname
and act_runner doesn't override it. So `--volumes-from docker` looks for
a container literally named "docker", finds nothing, exits.

This worked in earlier runs (#4260) only because config.yaml *wasn't
being loaded* (see iter18 commit), so the runner ran on its built-in
defaults — which kept the container's hostname as the auto-generated
container ID. Fixing config.yaml exposed this latent bug.

Right way to learn your own container ID inside a Linux container is
/proc/self/cgroup, which contains the 64-char hex ID on every cgroup
driver:
  cgroup v1: 12:devices:/docker/<64-hex>
  cgroup v2: 0::/system.slice/docker-<64-hex>.scope

awk extracts the first 64-hex run; that becomes the --volumes-from
argument. If extraction fails (would only happen on a non-docker
runtime), fail loud rather than silent.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 17:59:48 +01:00
..