From ad9e55d83e89fe726377f677a7461bb463d6c0a1 Mon Sep 17 00:00:00 2001 From: kristianwind Date: Thu, 17 Sep 2026 00:53:45 +0200 Subject: [PATCH] Make the site test's resource names unique per run, not per PID MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Gitea site test has been red since 03b0e13, and the cause was not the disk: Error response from daemon: network with name wpci-147-net already exists id was "wpci-$$". A Gitea job runs in a fresh container where the shell gets a low PID, and those REPEAT across runs — so the name collides with the leftovers of any earlier run that did not clean up, and every subsequent run landing on the same PID is wedged permanently. The same script never collides on a laptop, where PIDs are large and varied, which is why this was invisible outside the runner. That also corrects something this repo believed: "the containers are already safe (wpci-)" was written about concurrent sessions on one machine, where it is true. It does not hold across container boundaries, where the PID space restarts. Two changes. The name now carries the epoch and $RANDOM, so it is unique per run even in a container that always starts at the same PID. And because the name is now unique to this run, anything already using it is debris from a crashed run and is ours to clear, so the containers and network are removed before they are created — without that, one wedged name stays wedged forever, which is what happened here. Proven both ways: staging a stale wpci-147-net reproduces the exact daemon error under the old scheme, and the new pre-remove creates cleanly over it. Two consecutive real site tests then ran green, leaving zero wpci-* networks and zero wpci-* containers, with no leak warning from the check added in the previous commit. Worth recording how that was measured. A global `docker volume ls | wc -l` around one of those runs showed a delta of 2 — none of it this run's. Several sessions share this box and run these container pairs concurrently, so a neighbour's volumes read as your leak. The attributed check inside cleanup(), which asks the containers what they own, reported nothing and was right. Co-Authored-By: Claude Opus 5 (1M context) --- ci/site-test.sh | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/ci/site-test.sh b/ci/site-test.sh index f42c4fe..b67b9e2 100755 --- a/ci/site-test.sh +++ b/ci/site-test.sh @@ -25,8 +25,23 @@ WP_VERSION="${WP_VERSION:-latest}" WC_VERSION="${WC_VERSION:-latest}" PHP_VERSION="${PHP_VERSION:-8.3}" -id="wpci-$$" +# 🔴 NOT just $$. A Gitea job runs in a fresh container where the shell gets a +# low PID, and those REPEAT across runs — so "wpci-$$" collides with the +# leftovers of any earlier run that did not clean up, and the job dies on +# `network with name wpci-147-net already exists`. Measured on Gitea run 999: +# every run landing on PID 147 was wedged permanently, while the same script on +# a laptop never collides because PIDs there are large and varied. +# +# The epoch and $RANDOM make the name unique per run even inside a container +# that always starts at the same PID. +id="wpci-$$-$(date +%s)-${RANDOM:-0}" net="$id-net" + +# The name is unique to this run, so anything already using it is debris from a +# crashed run and is ours to clear. Without this a single wedged name stays +# wedged forever, which is exactly what happened on the Gitea runner. +docker rm -f -v "$id-db" "$id-cli" >/dev/null 2>&1 || true +docker network rm "$net" >/dev/null 2>&1 || true # 🔴 -v, and it is the whole bug. `mariadb:lts` declares VOLUME # /var/lib/mysql, so every run creates an ANONYMOUS volume, and `docker rm -f` # does not remove anonymous volumes — only `docker rm -f -v` does. The named