jakman85andClaude Opus 4.8
242951a000
The act_runner container's startup wait checked only for the dind TLS cert FILE (/certs/client/ca.pem), but dockerd writes the certs before it begins accepting TLS connections on :2376. A runner that proceeds on the file alone still hard-exits with "cannot ping the docker daemon at tcp://localhost:2376", a startup race observed crashlooping the pod during node bounces / slow containerd starts (11 restarts in ~8 min on a fresh pod post-bounce). Add a second bounded wait (nc -z 127.0.0.1 2376, 60s cap, mirroring the existing cert-file loop) so the runner starts only once the daemon actually accepts a connection. Self-healing, minimal, reversible. `nc` is present in the gitea/act_runner:0.2.11 image (verified). apps/wave-1/gitea-actions.yaml is a hand-authored EXTRA_UNIT raw manifest (render.py only places it into a wave, never regenerates its bytes), so this edit is at its source of truth; the canonical render does not emit the file and render==golden is unaffected (gate green). Co-Authored-By: Claude Opus 4.8 <[email protected]>
apps
App-tier manifests, rendered from catalog/*.yaml ServiceDefinitions by catalog/render.py
and split into dependency-ordered waves (wave-<N>/).
- Each
wave-<N>/is reconciled by its own Flux Kustomizationapps-wave-<N>(clusters/base/apps-wave-<N>.yaml), whichdependsOnwave N-1 (wave 0 dependsOnplatform-config) and health-gates (wait: true) ONLY that wave. A crashlooping workload in a later wave can no longer stall an earlier wave or block new revisions. wave-<N>/kustomization.yamlandclusters/base/apps-wave-<N>.yamlare generated — runpython3 catalog/render.py --emit-wavesafter onboarding a service; do not hand-edit them.- Wave assignment = longest dependency-path depth over the catalog
dependencies:graph; a co-located CNPG database<svc>-dbis a leaf and always lands strictly below its consumer.
See ../DESIGN-waves.md for the wave table, Flux topology, and the
cutover runbook.