`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.
What hid it: cleanup() removed the containers, the network and the NAMED $id-wp
volume correctly. Three of the four things the run creates. Removing three of
four is indistinguishable from removing all four unless you count, which is the
same shape as every other bug found in this kit today.
Found by the subscriptions session, which traced the Gitea runner's disk being
100% full — 26 GB in 95 volumes with 1 in use — and by woo-cache-manager from
the other end, whose push failed with `unable to create temporary object
directory`, three layers away from the cause. Measured here rather than taken
on report: a mariadb:lts container creates exactly one anonymous volume, it
survives `docker rm -f`, and it is removed by `docker rm -f -v`. This machine
was holding 133 volumes, 127 dangling, 15.2 GB reclaimable.
The fix is the -v. The rest is so it cannot come back silently:
cleanup() now asks the containers which volumes they own, via docker inspect,
BEFORE removing them, and checks afterwards that none survive. Attribution
rather than a global before/after count on purpose — several sessions share
this box and run these container pairs concurrently, so a neighbour's volume
would read as this run's leak.
The check is advisory on a run that already failed, and fatal on one that
otherwise passed: site_test_ok is set at the single point the run is known to
have succeeded. And it calls exit rather than return, because `return` from an
EXIT trap does not change the script's exit status — the warning would have
printed while the build went green, which is the failure mode this whole day
has been about.
Verified: the real site test now runs green with a volume delta of zero.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
