From b6e9c07c06678b215aa8cee630ef200099be9827 Mon Sep 17 00:00:00 2001 From: Sluijsens Date: Sun, 2 Aug 2026 11:24:41 +0200 Subject: [PATCH] Replaces the backend-test MariaDB service with an explicit docker run 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 Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN --- .gitea/workflows/continuous_integration.yaml | 46 +++++++++++++------- 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/.gitea/workflows/continuous_integration.yaml b/.gitea/workflows/continuous_integration.yaml index f44dd86..6671d5d 100644 --- a/.gitea/workflows/continuous_integration.yaml +++ b/.gitea/workflows/continuous_integration.yaml @@ -134,32 +134,48 @@ jobs: # other test project here, which mocks/uses EF Core InMemory and never touches a real # database. Without a real, reachable MariaDB, those tests fail on the connection itself # before any assertion runs. - services: - mariadb: - image: mariadb:11 - env: - MARIADB_ROOT_PASSWORD: ci_test_password - MARIADB_DATABASE: SlpModularCms - ports: - - 3306:3306 - options: >- - --health-cmd="mysqladmin ping --silent" - --health-interval=10s - --health-timeout=5s - --health-retries=5 + # + # A `services:` block was tried first and rejected: this runner uses host networking for + # job AND service containers ("--network and --net in the options will be ignored" in the + # job log), so the `ports:` mapping was silently ignored, and the mariadb:11 service ended + # up sharing the host's network namespace directly on port 3306 -- which something else on + # this runner already answers on (root auth was rejected by a server that was clearly NOT + # the freshly-initialized container: "Access denied ... using password: YES" against a + # password nothing but this job ever set). An explicitly `docker run` container below, + # published on host port 3307 instead of 3306, avoids that collision entirely. steps: - uses: actions/checkout@v4 - uses: actions/setup-dotnet@v4 with: dotnet-version: ${{ env.DOTNET_VERSION }} + - name: Start MariaDB for SlpModularCms.Api.Tests + run: | + docker run -d --name ci-mariadb \ + -e MARIADB_ROOT_PASSWORD=ci_test_password \ + -e MARIADB_DATABASE=SlpModularCms \ + -p 3307:3306 \ + mariadb:11 + for i in $(seq 1 30); do + # mariadb:11 does not provide a `mysqladmin` alias -- verified locally against this + # exact image; the correct binary here is `mariadb-admin`. + if docker exec ci-mariadb mariadb-admin ping -uroot -pci_test_password --silent 2>/dev/null; then + echo "MariaDB is ready." + break + fi + echo "Waiting for MariaDB... ($i/30)" + sleep 2 + done - name: Test (Release) env: # Overrides the placeholder in SlpModularCms.Api/appsettings.Development.json for this # CI run only -- ASP.NET Core's configuration layering applies environment variables # after appsettings.*.json, so this reaches SlpModularCms.Api.Tests' WebApplicationFactory - # without touching any committed appsettings file. - ConnectionStrings__DefaultConnection: "Server=127.0.0.1;Port=3306;Database=SlpModularCms;Uid=root;Pwd=ci_test_password" + # without touching any committed appsettings file. Port 3307, not 3306 -- see above. + ConnectionStrings__DefaultConnection: "Server=127.0.0.1;Port=3307;Database=SlpModularCms;Uid=root;Pwd=ci_test_password" run: dotnet test SlpModularCms.sln -c Release + - name: Stop MariaDB for SlpModularCms.Api.Tests + if: always() + run: docker rm -f ci-mariadb || true # --- Gate 3: vulnerability scan --- # `dotnet list package --vulnerable` always exits 0, even when it reports vulnerabilities, so the