Another fix to live-test workflow.

Author: rcbjBlueMars

.github/workflows/website-test-live-prod.yml

@@ -2,7 +2,7 @@ name: Live Site Test (idptools.com)
 
 # Runs the full Selenium suite against the DEPLOYED PROD site
 # (https://idptools.com), using a throwaway Keycloak spun up locally (browser
-# reaches it at http://keycloak:8080 on the compose network). Same mechanism as
+# reaches it at http://localhost:8080 via host networking). Same mechanism as
 # the test-site live test (docker-compose-live-tests.yml), pointed at prod via
 # LIVE_DEBUGGER_BASE_URL / LIVE_CONFIG_FILE.
 #

.github/workflows/website-test-live.yml

@@ -1,10 +1,9 @@
 name: Live Site Test (test.idptools.com)
 
 # Runs the full Selenium suite against the DEPLOYED test.idptools.com site,
-# using a throwaway Keycloak spun up locally (postgres + keycloak on a compose
-# network, same stack as the containerized suite). The browser in the tests
-# container reaches that Keycloak at http://keycloak:8080 while it drives the
-# public HTTPS site. See docker-compose-live-tests.yml.
+# using a throwaway Keycloak spun up locally over host networking. The browser
+# in the tests container reaches that Keycloak at http://localhost:8080 while it
+# drives the public HTTPS site. See docker-compose-live-tests.yml.
 #
 # Runs automatically after a successful test-site deploy (post-deploy
 # verification), plus nightly and on demand.

docker-compose-live-tests.yml

@@ -1,103 +1,53 @@
 # Runs the Selenium suite against a DEPLOYED debugger site (default:
 # https://test.idptools.com) while talking to a throwaway Keycloak spun up
-# locally. This is the same stack as docker-compose-run-tests.yml (postgres +
-# keycloak + tests on the "keycloak" bridge network) MINUS the containerized
-# api/client — the debugger under test is the hosted site instead.
+# locally. Same idea as docker-compose-run-tests.yml, but the debugger under
+# test is the hosted site instead of a containerized client — only Keycloak and
+# the test runner are started here.
 #
-# The browser inside the tests container reaches the local Keycloak at
-# http://keycloak:8080 (compose DNS), exactly as the containerized suite does.
-# It drives the public HTTPS site and makes its OIDC/OAuth calls to that local
-# Keycloak; the suite's Chrome flags (--allow-running-insecure-content +
-# private-network overrides) permit the HTTPS-page -> http://keycloak calls.
+# HOST NETWORKING is required (not the bridge network the containerized suite
+# uses): the browser drives the public HTTPS site and must call the local
+# Keycloak from that HTTPS page. Chrome treats http://localhost (loopback) as
+# potentially-trustworthy and exempt from mixed-content / private-network
+# blocking, but a private-IP host (e.g. a bridge service name) is blocked. So
+# both containers share the host network and Keycloak is reached at
+# http://localhost:8080 — exactly the scenario remote-run-tests.sh proves.
 #
-# Keycloak's clients are (re)created at run time by common.sh configureKeycloak
-# with redirectUris/webOrigins matching DEBUGGER_BASE_URL, so the deployed
-# site's redirect back to <site>/callback validates.
-#
-# Compose format 2.x for `depends_on: condition: service_healthy` support.
+# Readiness: instead of a Docker healthcheck (flaky under host networking), the
+# tests container waits for Keycloak itself (docker-run-tests.sh waitForKeycloak).
 #
 # Override the target via the environment:
 #   LIVE_DEBUGGER_BASE_URL (default https://test.idptools.com)
 #   LIVE_CONFIG_FILE        (default ./env/test-idptools-com.js)
 services:
-  postgres:
-    image: postgres:18
-    volumes:
-      - postgres_data:/var/lib/postgresql/data
-    environment:
-      POSTGRES_USER: keycloak
-      POSTGRES_PASSWORD: keycloak
-      POSTGRES_DB: keycloak
-      # postgres:18 refuses to start on a data dir initialized by an older
-      # major version. Initialize into a fresh subdirectory of the volume so
-      # the upgrade starts cleanly (test data is disposable and recreated each
-      # run); any legacy PG17 files at the volume root are ignored.
-      PGDATA: /var/lib/postgresql/data/pgdata
-    healthcheck:
-      test: pg_isready
-      interval: 10s
-      timeout: 60s
-      retries: 5
-      start_period: 45s
-    networks:
-      - keycloak
-
   keycloak:
     image: quay.io/keycloak/keycloak:26.6.4
     command: ["start-dev"]
+    hostname: keycloak
+    network_mode: "host"
     environment:
-      KC_DB: postgres
-      KC_DB_URL: jdbc:postgresql://postgres:5432/keycloak
-      KC_DB_USERNAME: keycloak
-      KC_DB_PASSWORD: keycloak
+      KC_HTTP_PORT: "8080"
+      KC_BOOTSTRAP_ADMIN_USERNAME: keycloak
+      KC_BOOTSTRAP_ADMIN_PASSWORD: keycloak
       KEYCLOAK_ADMIN: keycloak
       KEYCLOAK_ADMIN_PASSWORD: keycloak
       KC_HEALTH_ENABLED: "true"
-    hostname: keycloak
-    healthcheck:
-      test: [
-        "CMD-SHELL",
-        "exec 3<>/dev/tcp/localhost/9000; \
-        echo -en 'GET /health/ready' >&3; \
-        # Give the server a moment to respond, then search for 'UP'
-        if timeout 3 cat <&3 | grep -m 1 'UP'; then \
-          exec 3<&-; exec 3>&-; exit 0; \
-        else \
-          exec 3<&-; exec 3>&-; exit 1; \
-        fi"
-      ]
-      interval: 10s
-      timeout: 60s
-      retries: 5
-      start_period: 30s
-    depends_on:
-      postgres:
-        condition: service_healthy
-    networks:
-      - keycloak
 
   tests:
     image: rcbj/test-live
     build:
       context: .
       dockerfile: tests/Dockerfile
+    network_mode: "host"
     environment:
-      # Target the deployed site; talk to the local Keycloak by service name.
+      # Target the deployed site; talk to the local Keycloak over loopback.
       - DEBUGGER_BASE_URL=${LIVE_DEBUGGER_BASE_URL:-https://test.idptools.com}
-      - KEYCLOAK_BASE_URL=http://keycloak:8080
-      - KEYCLOAK_LOCALHOST_BASE_URL=http://keycloak:8080
+      - KEYCLOAK_BASE_URL=http://localhost:8080
+      - KEYCLOAK_LOCALHOST_BASE_URL=http://localhost:8080
       - CONFIG_FILE=${LIVE_CONFIG_FILE:-./env/test-idptools-com.js}
     # Persist the generated report/logs to the host (gitignored).
     volumes:
       - ./tests/report:/usr/src/app/report
+    # Start-order only (host networking healthchecks are unreliable); the test
+    # runner waits for Keycloak to answer before configuring it.
     depends_on:
-      keycloak:
-        condition: service_healthy
-    networks:
       - keycloak
-
-volumes:
-  postgres_data:
-
-networks:
-  keycloak:

docker-run-tests.sh

@@ -39,8 +39,36 @@ runReport()
   node "${NODEJS_BASE_DIR}/run-report.js"
 }
 
+# Poll until Keycloak answers before configuring it. In the fully-containerized
+# stack Keycloak is already up (compose depends_on: service_healthy), so this
+# returns immediately; in the live-site stack (host networking, no healthcheck
+# gate) this is what actually waits for Keycloak to come up.
+waitForKeycloak()
+{
+  echo "Waiting for Keycloak at ${KEYCLOAK_LOCALHOST_BASE_URL} ..."
+  local i=0
+  local max=60
+  local code
+  while [ $i -lt $max ];
+  do
+    code=$(curl -s -o /dev/null -w '%{http_code}' \
+      "${KEYCLOAK_LOCALHOST_BASE_URL}/realms/master/.well-known/openid-configuration" || true)
+    if [ "${code}" = "200" ];
+    then
+      echo "Keycloak is ready."
+      return 0
+    fi
+    i=$((i + 1))
+    sleep 3
+  done
+  echo "ERROR: Keycloak did not become ready at ${KEYCLOAK_LOCALHOST_BASE_URL} within timeout." >&2
+  exit 1
+}
+
 init
 check_return_code $?
+waitForKeycloak
+check_return_code $?
 configureKeycloak
 check_return_code $?
 runReport