SluijsensandClaude Sonnet 5
b6e9c07c06
Continuous Integration / config (pull_request) Successful in 12s
Continuous Integration / changes (pull_request) Successful in 22s
Continuous Integration / backend-build (pull_request) Successful in 5m41s
Continuous Integration / vulnerability-scan (pull_request) Successful in 5m8s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m52s
Continuous Integration / backend-test (pull_request) Successful in 7m35s
Continuous Integration / frontend-build (pull_request) Successful in 2m18s
Continuous Integration / frontend-test (pull_request) Successful in 4m43s
Continuous Integration / frontend-lint (pull_request) Successful in 2m15s
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Continuous Integration / publish-test (pull_request) Successful in 7m7s
Continuous Integration / deploy-test (pull_request) Skipped
The services: block was silently broken on this runner: job and service containers both use host networking here, so the ports: mapping was ignored and the mariadb:11 service ended up sharing the host's own port 3306 -- which something else on this runner already answers on (root auth was rejected with a password nothing but this job ever set). Replaced with an explicit `docker run` on host port 3307, bypassing that collision, plus a readiness loop. Also fixes the readiness command itself: mariadb:11 does not provide a `mysqladmin` alias, the correct binary is `mariadb-admin` (verified locally against the exact image before pushing this). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN