From bc9d6355af3bd5899256c95e893e3f5053029d0d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20B=C3=BCrk?= Date: Thu, 30 Jul 2026 10:50:07 +0200 Subject: [PATCH] [BUGFIX] Wait longer for database readiness waitFor() capped the readiness poll at 11 iterations of "sleep 1", so roughly 11 seconds. Measured against the same images, the time from "run -d" until the port accepts connections is: mysql:8.0 podman 7.0-7.2s docker 12.2-13.2s mariadb:10.4 podman 7.8s docker 8.2s postgres:10 podman 1.3s docker 1.5s Only mysql crosses that limit, and only under docker, whose entrypoint needs about twice as long to initialise a fresh data directory. The workflows select docker now, so the functional mysql suites began to abort intermittently. The cap is 60 seconds instead, which also leaves mariadb a sensible margin. The abort also did not abort. "kill -SIGINT -$$" relies on the SIGINT trap, and that trap is only installed when CI is not "true". In CI the kill was a no-op, so the script carried on and ran the test suite against a database that was not listening, which then reported dozens of "Connection refused" errors instead of the readiness timeout that had actually occurred. waitFor() cleans up and exits directly now. --- Build/Scripts/runTests.sh | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/Build/Scripts/runTests.sh b/Build/Scripts/runTests.sh index f0a45e1..64e849d 100755 --- a/Build/Scripts/runTests.sh +++ b/Build/Scripts/runTests.sh @@ -10,10 +10,13 @@ fi waitFor() { local HOST=${1} local PORT=${2} + # 60 rather than 10 seconds: mysql:8.0 needs 12-13s under docker to + # initialise a fresh data directory, about twice as long as under podman, + # so an 11 second budget aborted the functional mysql suites at random. local TESTCOMMAND=" COUNT=0; while ! nc -z ${HOST} ${PORT}; do - if [ \"\${COUNT}\" -gt 10 ]; then + if [ \"\${COUNT}\" -gt 60 ]; then echo \"Can not connect to ${HOST} port ${PORT}. Aborting.\"; exit 1; fi; @@ -23,7 +26,11 @@ waitFor() { " ${CONTAINER_BIN} run ${CONTAINER_COMMON_PARAMS} --name wait-for-${SUFFIX} ${XDEBUG_MODE} -e XDEBUG_CONFIG="${XDEBUG_CONFIG}" ${IMAGE_PHP} /bin/sh -c "${TESTCOMMAND}" if [[ $? -gt 0 ]]; then - kill -SIGINT -$$ + # Not "kill -SIGINT -$$": the SIGINT trap is only installed when CI is + # not "true", so in CI the signal was a no-op, the run continued and the + # test suite connected to a database that was not listening. + cleanUp + exit 1 fi }