mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-13 14:16:46 +00:00
kevinveenbirkenbachandClaude Opus 4.7
d1de165e9c
`docker compose down --remove-orphans` only deletes networks that compose itself created (those carrying `com.docker.compose.network=default` + `com.docker.compose.project=<name>` labels). When the per-entity default network ends up unlabeled or project-mislabeled — typical after an inter-round matrix-deploy purge, or when a `community.docker.docker_network` Ansible call materialised the network before compose ran — compose deliberately leaves it untouched, and a subsequent `compose up` aborts with network <entity> was found but has incorrect label com.docker.compose.network set to "" (expected: "default") The matrix-deploy CI rounds for web-app-matrix, web-app-gitea and others reliably reproduce this. Add a new entity-keyed purge primitive `scripts/container/purge/entity/network.sh <ENTITY>` that runs after the compose / dir / nginx primitives. It is idempotent: no-op when the network does not exist, skips removal while active container endpoints prove the network belongs to a shared service still in use (svc-db-mariadb, svc-db-postgres, svc-db-openldap, svc-ai-ollama, …), and otherwise drops the orphan network with `docker network rm`. `docker network rm` failures are logged and tolerated — the next `compose up` will surface the same problem with an actionable error. Wire the primitive into `scripts/container/purge/apps.sh` immediately after the existing `nginx.sh` call, so every entity-keyed purge collects its own default network on the same pass. Finally, after the entity loop, run a single bare `docker network prune -f` to sweep orphan networks whose name does NOT correspond to a purged entity (left over from renamed roles, abandoned matrix-deploy rounds, etc.). The sweep is bare on purpose — no `|| true` guard — so a daemon-side prune failure aborts the purge loudly via the script's `set -euo pipefail`. Performance: ~13× faster than calling prune inside `network.sh` per entity (one ~200 ms listing pass vs. N × 200 ms for N entities). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>