Lockfile GitHub Actions przypina kod uruchamiany w CI, ale nie obejmuje całego CI

Czy można ufać GitHub Actions, jeśli workflow odwołuje się do akcji przez tag, na przykład @v3? Lockfile precyzuje, który commit akcji zostanie uruchomiony, nawet jeśli tag zostanie później przesunięty. Zespół może przeglądać aktualizacje zależności w diffie i prowadzić weryfikowalny wykaz akcji używanych przez CI. Ważne ograniczenie: lockfile obejmuje akcje wywoływane w krokach, natomiast reusable workflow wywoływany na poziomie zadania trzeba przypiąć osobno. Opisany mechanizm jest dostępny w GitHub Enterprise Cloud.

Co dokładnie przypina lockfile?

Odwołania do gałęzi i tagów są wygodne, ale wskazywana przez nie wersja może się zmieniać. Zapis taki jak uses: octo-org/deploy-action@v3 wskazuje nazwę tagu; GitHub rozwiązuje to odwołanie do commita podczas uruchomienia. Jeśli właściciel projektu przesunie tag, kolejne uruchomienie bez przypiętej zależności może pobrać inny kod.

Zgodnie z dokumentacją GitHub dotyczącą lockfile, plik .github/workflows/actions.lock przechowuje odwołania do zależności i odpowiadające im commity SHA, w tym zależności przechodnie — akcje używane przez inne akcje. Plik tworzy rozszerzenie GitHub CLI gh actions-lock; nie edytuje się go ręcznie.

Generator może również doprecyzować odwołania uses w plikach workflow: na przykład zamienić odwołanie do ruchomego tagu na bardziej konkretne, zachowując commit, na który wskazywało podczas tworzenia lockfile. Dlatego przy wdrażaniu należy przejrzeć cały diff — zmiany w workflow i lockfile — oraz sprawdzić, czy przypięta wersja jest tą, którą zespół zamierza uruchamiać.

Dzięki temu aktualizacja zależności staje się widoczną zmianą w repozytorium: zespół może sprawdzić zmianę commita, omówić ją i zaakceptować w ramach standardowego przeglądu. Lockfile pomaga audytować kod akcji i zachować spójność zależności; sam w sobie nie potwierdza bezpieczeństwa wybranego kodu.

Gdzie kończy się zakres przypinania?

Wywołanie reusable workflow w jobs.<job_id>.uses nie jest przypinane przez lockfile repozytorium, które je wywołuje. Zależności reusable workflow należą do repozytorium, w którym ten workflow jest zdefiniowany. Aby przypiąć samo wywołanie, podaj pełny commit SHA; aby przypiąć jego akcje w repozytorium źródłowym, potrzebny jest tam osobny lockfile.

Lockfile kontroluje kod akcji, ale nie inne elementy procesu budowania, takie jak parametry przekazywane akcji, sekrety czy obraz runnera. Odpowiada na konkretne pytanie: który commit kodu akcji zostanie uruchomiony? Pozostałe elementy wymagają własnych zasad zarządzania.

Szczególnym przypadkiem jest lokalna akcja wywoływana przez ścieżkę w rodzaju uses: ./. Według instrukcji GitHub rozszerzenie gh actions-lock nie przypina ani nie analizuje lokalnej ścieżki akcji. Jeśli taka akcja używa innych akcji, ich zależności trzeba kontrolować osobno; dokumentacja opisuje możliwość migracji odwołań do lokalnych akcji do formatu $/.

W efekcie pojedynczy wpis w lockfile może być częścią łańcucha, ale nie zastępuje kontroli wszystkich jego ogniw. W przypadku zewnętrznego reusable workflow sprawdź przypięcie wywołania i stan repozytorium źródłowego; w przypadku lokalnych akcji sprawdź, w jaki sposób uwzględniono ich zależności.

Jak wdrożyć kontrolę bez niespodziewanych przestojów CI?

GitHub zaleca rozpoczęcie od pilotażu w wybranych repozytoriach i workflow. Polityka Require lockfile blokuje uruchomienie wskazanych workflow bez prawidłowego lockfile, także tych, które nie zawierają zależności uses:. Tryb Evaluate dla polityk jest dostępny tylko w GitHub Enterprise Cloud. Dlatego najpierw przygotuj zakres i automatyczne aktualizacje, a dopiero potem włącz wymaganie.

1. Sprawdź istniejące odwołania. Przed utworzeniem lockfile upewnij się, że akcje wskazują wersje, które zespół rzeczywiście chce przypiąć. Generator przypina commit rozpoznany na podstawie bieżącego odwołania.
2. Utwórz lockfile i przejrzyj go. Zainstaluj rozszerzenie gh-actions-lock, uruchom gh actions-lock w katalogu głównym repozytorium i przejrzyj cały diff, w tym przepisane odwołania uses.
3. Skonfiguruj aktualizacje i weryfikację. Dependabot może aktualizować odpowiednie wpisy w już podłączonych workflow. W CI pull requestu można skonfigurować zadanie weryfikacyjne z gh actions-lock --verify, aby wykrywać nieaktualny lockfile przed głównym procesem budowania.
4. Wyznacz recenzentów. Dodaj .github/workflows/actions.lock do CODEOWNERS i wymagaj przeglądu zmian przez osoby odpowiedzialne za bezpieczeństwo procesu budowania.
5. Przeprowadź pilotaż polityki. Zacznij od podłączonych repozytoriów i workflow. W trybie Evaluate przeanalizuj wyniki; przed włączeniem trybu Active sprawdź, czy wszystkie wskazane workflow są przygotowane, a lockfile pozostają aktualne.

Require lockfile i osobna polityka Require actions to be pinned to a full-length commit SHA to różne reguły; GitHub wskazuje, że można stosować je równocześnie. Kontrola w CI i obowiązkowa polityka również pełnią różne funkcje: pierwsza wykrywa nieaktualny plik podczas pracy nad pull requestem, druga blokuje uruchomienie workflow, który nie spełnia wymagań.

Przykład: aktualizacja akcji wdrożeniowej

Załóżmy, że workflow publikuje aplikację za pomocą octo-org/deploy-action@v3. Najpierw zespół sprawdza, którą wersję wskazuje to odwołanie, a następnie uruchamia gh actions-lock i analizuje diff workflow wraz z wpisem commita w lockfile. Podczas aktualizacji akcji osoba weryfikująca widzi zmiany odwołań i przypiętego commita; może dzięki temu ocenić konkretną aktualizację, zamiast zakładać, że ruchomy tag zawsze wskazuje ten sam kod.

Jeśli wdrożenie wykonuje reusable workflow z innego repozytorium, lokalny lockfile nie obejmuje jego zależności. Przypnij odwołanie do reusable workflow pełnym SHA i sprawdź, czy repozytorium źródłowe zarządza własnymi zależnościami akcji. W dużych organizacjach takie podejście zmienia rozproszone zasady w weryfikowalny proces, pozostawiając osobną kontrolę parametrów, sekretów i runnera.

Lockfile jest przydatną warstwą kontroli kodu akcji: zapewnia przejrzystość wersji i aktualizacji, w tym zależności przechodnich. Aby uzyskać wiarygodny zakres ochrony, sprawdź także reusable workflows i lokalne akcje, zautomatyzuj aktualizacje i wprowadzaj obowiązkową politykę dopiero po pilotażu.