The deferred-since-day-one cache-server gap (documented as
"Cache server (deferred)" in infra/README.md, mentioned every
time we hit a slow CI install). Root cause: act_runner's
built-in cache server binds inside the runner container and
advertises an IP on the compose-defined `apf-portal-act-runners`
bridge — but jobs are spawned via the mounted /var/run/docker.
sock, which puts them on Docker's anonymous default `bridge`
instead. The advertised URL is unreachable from the job, every
cache request burns a ~2 min ETIMEDOUT (restore + save), the
hit rate is zero.
Fix: tell act_runner to attach jobs to the same compose-defined
bridge as the runners, via `container.network` in the shared
runner-config.yaml. The advertised cache URL becomes a normal
internal-network DNS hop, jobs reach the cache server, and
`cache: 'pnpm'` works end-to-end.
The blast-radius trade-off is bounded: every container on the
apf-portal-act-runners network is one of our runner containers
(plus the jobs they spawn), all of which already have full
docker-socket access. Sharing a network does not widen what a
malicious workflow can already do; it just lets jobs reach the
cache server.
Changes:
- infra/runner-config.yaml: add `container.network: apf-portal-
act-runners`. Surface the `cache.enabled: true` default
explicitly so a future contributor knows where the toggle is.
- .gitea/workflows/ci.yml: re-enable `cache: 'pnpm'` on every
actions/setup-node step (5 jobs). Drop the now-stale block
comment that explained the disablement.
- .gitea/workflows/security-scheduled.yml: same on the two
setup-node steps in this workflow.
- infra/README.md "Cache server" section rewritten — was
"(deferred)", now describes the working setup, with the
rationale and blast-radius note. The disable toggle is
documented inline.
- ci.yml's Trivy comment trimmed to drop the cross-reference to
the deferred-cache-server section that no longer exists.
Roll-out on the runner host (manual, post-merge):
cd <repo>/infra
git pull
./ci-runners.sh rotate
`rotate` recreates the containers with the new
runner-config.yaml mount intact. The first CI job after rollout
seeds the cache from cold (~30-60 s install); subsequent jobs
should report `reused N` instead of `downloaded N` in the
`pnpm install --frozen-lockfile` line and finish a few minutes
faster overall.
## Summary
`act_runner`'s default `container.force_pull: true` re-issues a `docker pull` at the start of every job, adding 10–30 s of registry round-trip even when every layer is already locally cached. With job images pinned to specific tags (`catthehacker/ubuntu:act-22.04` and `:full-22.04`), the implicit pull is pure overhead and contradicts the deliberate-upgrade policy ADR-0015 spells out for the runner image.
- Add `infra/runner-config.yaml` with `container.force_pull: false`.
- Mount it read-only into all three runners and point each at it via `CONFIG_FILE=/etc/runner/config.yaml`.
- Document the pre-pull procedure and image-upgrade playbook in `infra/README.md` → "Job image pinning and pre-pull".
- Fold the pre-pull into the "First-time registration" walkthrough so a fresh setup is correct end-to-end.
The trade-off: the runner host must hold the images locally before the runner is asked to use them. Documented.
## Roll-out (manual, on the runner host)
```bash
cd infra/
# 1. Pre-pull the job images (one-shot — pays the cold cost once).
docker pull catthehacker/ubuntu:act-22.04
docker pull catthehacker/ubuntu:full-22.04
# 2. Recreate the runners so the new mount + env var take effect.
docker compose -f ci-runners.compose.yml up -d --force-recreate
---------
Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #10
Julien Gautier
julien