Josh Knapp
e58454c1cc
All checks were successful
HAProxy Manager Build and Push / Build-and-Push (push) Successful in 1m10s
Mirror base images / Mirror-Base (map[dst_path:cloud-hosting-platform/golang src:docker.io/library/golang:1.25 tag:1.25]) (push) Successful in 34s
Mirror base images / Mirror-Base (map[dst_path:cloud-hosting-platform/python src:docker.io/library/python:3.12-slim tag:3.12-slim]) (push) Successful in 9s
Procedural discipline for shipping haproxy-manager-base changes. The flow differs from WHP's (Gitea Actions auto-build vs. build-release.sh, docker pull + recreate vs. update.sh) and has its own foot-guns worth codifying: - /etc/haproxy is a named volume → baked-in image files under that path are shadowed on existing deployments; use /haproxy/ instead - HAProxy lf-file expansion eats single % → literal CSS percentages must be doubled (100%%) - WAF-block synthetic test ACL must be injected AFTER send-spoe-group or the SPOE call overwrites the forced action - coraza-spoa is distroless (no sh); peek inside with docker create + docker cp rather than docker exec sh Both build paths (build-push.yaml for haproxy-manager-base, build- push-coraza.yaml for coraza-spoa) are surfaced so a contributor knows which CI run to watch. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>