Julien Gautier
4934fc29da
`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 per job even when every layer is already locally cached. The job images are already pinned to specific tags (catthehacker ubuntu :act-22.04 + :full-22.04), so the implicit pull is both pure overhead and contradictory with the deliberate-upgrade policy ADR-0015 spells out for the runner image itself. Mount a shared `infra/runner-config.yaml` into all three runners with `force_pull: false`, point each runner at it via the `CONFIG_FILE` env var, and document the pre-pull procedure (one-shot `docker pull` on the runner host, plus the upgrade playbook) in infra/README.md "Job image pinning and pre-pull". The pre-pull is also folded into the "First-time registration" walkthrough so a fresh setup is correct end-to-end.
17 lines
864 B
YAML
17 lines
864 B
YAML
# act_runner config — shared by all three runner instances defined
|
|
# in ci-runners.compose.yml. Mounted read-only at /etc/runner/config.yaml
|
|
# inside each container, selected via the CONFIG_FILE environment variable.
|
|
#
|
|
# Generated from `act_runner generate-config` and trimmed to the keys we
|
|
# actually need to override. Defaults for everything else.
|
|
# See: https://gitea.com/gitea/act_runner/src/branch/main/internal/pkg/config/config.example.yaml
|
|
|
|
container:
|
|
# Skip the per-job `docker pull` round-trip when the image is already
|
|
# cached locally. The default (true) re-checks the registry on every
|
|
# job start, adding 10-30s of latency per job for no value once the
|
|
# tag is pinned. Image upgrades happen deliberately on the runner
|
|
# host (see infra/README.md "Updating the runner job images") — not
|
|
# implicitly via :latest.
|
|
force_pull: false
|