CI failure: ci.yaml / gates #6
Labels
No labels
ci-failure:ci.yaml-gates
ci-failure:deploy.yaml-build-push-deploy
rollback-drill
rollback-fired:drill
rollback-fired:production
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
vendel.xi2ix.com/xi2ix.com-website#6
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Workflow: ci.yaml
Job: gates
Run: https://forgejo.lab.xi2ix.de/vendel.xi2ix.com/xi2ix.com-website/actions/runs/113
Commit:
0c6c2dd3caBranch/ref: main
Triggered by: vendel.xi2ix.com
Captured output (tail, per failing-eligible step)
/tmp/gsd-failhook-ci-gates-go-test.log
/tmp/gsd-failhook-ci-gates-lhci.log
/tmp/gsd-failhook-ci-gates-xss-ssti.log
Das ist vermutlich kein neuer Bug, sondern die bekannte, bewusst zurückgestellte LHCI/Chrome-Lücke aus Phase 45 (12.07.).
Kurzer Blick in den Log:
go test ./...läuft komplett grün durch (alle Paketeok), XSS/SSTI-Scan auch grün — nur der letzte Schritt, Lighthouse CI, scheitert mitRuntime error encountered: Unexpected server response: 404.Bei der Runner-Migration (Phase 45, unser Repo) hatten wir das bereits gefunden: LHCI braucht einen Chrome/Chromium-Binary, den der CI-Job-Container nicht hat — der Operator hat sich damals bewusst gegen einen schnellen
apt-get install chromium-Fix entschieden und stattdessen eine eigene Playwright-Farm-Phase für den Chrome-Zugriff eingeplant (noch nicht umgesetzt, offenes Todo in beiden Repos:2026-07-12-playwright-farm-lhci-chrome-endpoint.mdbei uns,2026-07-12-lhci-chrome-via-playwright-farm.mdbei euch).Falls das jetzt dringlicher wird als "nächste Phase irgendwann", sagt Bescheid — dann ziehen wir das vor. Ansonsten: kein neues Problem, kein Handlungsbedarf gerade.
Workflow: ci.yaml
Job: gates
Run: https://forgejo.lab.xi2ix.de/vendel.xi2ix.com/xi2ix.com-website/actions/runs/116
Commit:
346a5b147bBranch/ref: main
Triggered by: vendel.xi2ix.com
Captured output (tail, per failing-eligible step)
/tmp/gsd-failhook-ci-gates-go-test.log
/tmp/gsd-failhook-ci-gates-lhci.log
/tmp/gsd-failhook-ci-gates-xss-ssti.log
Workflow: ci.yaml
Job: gates
Run: https://forgejo.lab.xi2ix.de/vendel.xi2ix.com/xi2ix.com-website/actions/runs/119
Commit:
dfd64f3e4aBranch/ref: main
Triggered by: vendel.xi2ix.com
Captured output (tail, per failing-eligible step)
/tmp/gsd-failhook-ci-gates-go-test.log
/tmp/gsd-failhook-ci-gates-lhci.log
/tmp/gsd-failhook-ci-gates-xss-ssti.log
Workflow: ci.yaml
Job: gates
Run: https://forgejo.lab.xi2ix.de/vendel.xi2ix.com/xi2ix.com-website/actions/runs/124
Commit:
9b114a003cBranch/ref: main
Triggered by: vendel.xi2ix.com
Captured output (tail, per failing-eligible step)
/tmp/gsd-failhook-ci-gates-go-test.log
/tmp/gsd-failhook-ci-gates-lhci.log
/tmp/gsd-failhook-ci-gates-xss-ssti.log
Workflow: ci.yaml
Job: gates
Run: https://forgejo.lab.xi2ix.de/vendel.xi2ix.com/xi2ix.com-website/actions/runs/130
Commit:
7108af37b1Branch/ref: main
Triggered by: vendel.xi2ix.com
Captured output (tail, per failing-eligible step)
/tmp/gsd-failhook-ci-gates-go-test.log
/tmp/gsd-failhook-ci-gates-xss-ssti.log
Workflow: ci.yaml
Job: gates
Run: https://forgejo.lab.xi2ix.de/vendel.xi2ix.com/xi2ix.com-website/actions/runs/135
Commit:
09bfa0ddb4Branch/ref: plan/phase-06-grounded-ai-conversation
Triggered by: vendel.xi2ix.com
Captured output (tail, per failing-eligible step)
/tmp/gsd-failhook-ci-gates-go-test.log
/tmp/gsd-failhook-ci-gates-xss-ssti.log
Vollständige Analyse von unserer Seite — Empfehlung: Issue schließen.
Wir haben die komplette Historie dieses Issues durchgearbeitet (Forgejo-Kommentare + euer Repo direkt geklont +
.planning/debug/ci-gates-lhci-silent-fail.mdgelesen) und den kompletten CDP-Pfad live gegen den echtenxi2ix-website-runnergetestet:playwright-cdp.playwright.svc.cluster.local:9222liefert sauberes/json/version, korrektenwebSocketDebuggerUrl, echten WS-Upgrade-Handshake (HTTP 101). Getestet aus drei Positionen: nativer k8s-Pod, 3× sequentielle Lighthouse-Läufe gegen denselben Browser, und — am wichtigsten — aus einem Sibling-Docker-Container über euren DinD-Socket (docker runimdind-Container eures Runners), was exakt die Netzwerkposition eures echten CI-Jobs nachbildet. Alle drei liefen sauber durch, kein 404, keine Verbindungsprobleme. Auch keine Restarts/OOM/Crash-Loops implaywright-cdp-Pod (Restart Count 0, 2+ Tage stabil).ci.yaml-Wiring (--hostname/--port, POD_IP, DinD-Netzwerk-Discovery) ist bereits korrekt und mehrfach live-verifiziert (Run 84 u.a.) — kein Änderungsbedarf.k3s-worker-gp-2(eurem Runner-Node) im fraglichen Zeitfenster (20:28–21:39 UTC) — die eigentliche Ursache bleibt also vermutlich ein echter Timing-Flake in der Pre-Tee-Setup-Phase (Postgres-Start//livez/npm ci), nicht etwas, das wir clusterseitig sehen.79e2851, vollständiges Tee-Wrapping) ist bereits live und der unmittelbar folgendegates-Run aufmain(#1847) ist grün — also sowohl "Fix bricht nichts" als auch "LHCI läuft aktuell sauber durch" bestätigt.Fazit: Keine offene Infra-Lücke mehr. Playwright-Farm-CDP-Endpoint ist voll funktionsfähig und bewährt, euer Wiring korrekt. Der verbleibende Rest ist ein möglicher seltener Timing-Flake, der ab jetzt dank eures Fixes selbst-diagnostizierend ist, falls er wiederkommt. Von unserer Seite bereit zum Schließen — wir schließen es gleich, meldet euch einfach wieder, falls der Flake erneut auftritt und mehr Log-Detail zeigt, dann schauen wir sofort mit.