GitHub Actions: lockfile fixează codul rulat

GitHub a deschis previzualizarea publică a lockfile-urilor pentru GitHub Actions pe 14 octombrie 2026. Funcția este disponibilă pe planurile Free, Team, GitHub Enterprise Cloud și GitHub Enterprise Cloud cu rezidență a datelor. Pentru un workflow inclus în fișier, GitHub Actions rulează commiturile înregistrate chiar dacă tagul sau ramura care indică o acțiune se mută ulterior.

Riscul apare când o referință precum actions/checkout@v4 rămâne neschimbată în workflow, dar tagul ajunge să indice alt cod. Într-un test publicat de DevelopersIO pe 16 octombrie 2026, autorul a mutat tagul unei acțiuni și a pornit din nou workflow-ul: rularea a folosit în continuare commitul din lockfile. Testul a folosit un depozit pe planul Free și a verificat separat că o dependență adăugată fără actualizarea fișierului oprește execuția înainte de pornirea jobului.

Ce fixează fișierul actions.lock

Extensia gh actions-lock pentru GitHub CLI generează fișierul .github/workflows/actions.lock. În el sunt înregistrate commiturile pentru acțiunile apelate direct, pentru acțiunile pe care acestea le folosesc la rândul lor și pentru apelurile către workflow-uri reutilizabile. Referința din workflow poate rămâne un tag sau o ramură ușor de recunoscut; la rulare contează commitul asociat în fișier.

Acoperirea se face pentru fiecare workflow inclus. După includere, fiecare dependență a acelui workflow trebuie să aibă o intrare corespunzătoare, iar GitHub Actions folosește commitul înregistrat. Existența unui actions.lock în depozit nu înseamnă însă că toate workflow-urile sale au fost incluse. Cele rămase în afara fișierului continuă să rezolve referințele mobile la rulare.

În cazul unui workflow reutilizabil din alt depozit, fișierul depozitului apelant fixează referința către acel workflow. Acțiunile folosite în interiorul workflow-ului reutilizabil țin de lockfile-ul depozitului în care acesta este definit. Această delimitare contează pentru echipele care întrețin automatizări comune în mai multe depozite: fixarea apelului nu acoperă singură toate dependențele din interior.

Generarea și revizuirea schimbărilor

Fluxul începe cu referințele uses: versiunea indicată de fiecare tag sau ramură trebuie să fie cea pe care echipa intenționează să o fixeze. După instalarea extensiei, comanda gh actions-lock, rulată din rădăcina depozitului, parcurge workflow-urile din .github/workflows și generează fișierul. Pentru includerea unui singur workflow, comenzii i se transmite calea acelui fișier.

Diferența propusă trebuie citită în întregime, deoarece extensia poate modifica și fișierele workflow. De exemplu, poate înlocui o referință la o versiune majoră cu eticheta unei versiuni mai precise care indică același commit. Echipa poate astfel păstra o referință lizibilă, dar trebuie să verifice atât schimbarea din workflow, cât și commitul consemnat în actions.lock înainte de integrare.

O modificare a câmpului commit înseamnă că workflow-ul va rula alt cod. Ea merită aceeași atenție ca actualizarea oricărei dependențe: ce versiune a fost aleasă, ce schimbări aduce și dacă depozitul din spatele numelui este cel așteptat. Regenerarea automată a fișierului face diferența vizibilă, dar nu reprezintă o aprobare a codului rezultat.

Verificarea, CODEOWNERS și Dependabot

După includerea unui workflow, comanda gh actions-lock --verify poate fi folosită într-un pull request pentru a depista un lockfile rămas în urmă, fără să modifice fișierele. Când cineva adaugă sau elimină o dependență din uses, fișierul trebuie regenerat. În acest fel, eroarea ajunge la autorul modificării înainte ca o rulare să fie oprită din cauza unei intrări lipsă.

Pentru revizuirea schimbărilor, ghidul GitHub de administrare recomandă includerea .github/workflows/actions.lock în CODEOWNERS și o regulă care cere aprobarea unui responsabil desemnat. Același ghid descrie politica Require lockfile: în modul activ, aceasta blochează rulările workflow-urilor vizate care au dependențe, dar nu sunt incluse într-un lockfile valid. Documentația recomandă un pilot și un proces de actualizare a fișierelor înainte de activarea politicii la scară mai mare.

Dependabot poate prelua actualizările obișnuite ale versiunilor. Când propune într-un pull request o versiune nouă pentru o acțiune dintr-un workflow deja inclus, regenerează și intrarea corespunzătoare din lockfile. Referința din workflow și commitul fixat ajung astfel în aceeași modificare, pregătite pentru o singură revizuire. Dependabot nu include automat în fișier un workflow care nu avea deja intrări.

Ce rămâne de verificat după fixarea commitului

Un lockfile împiedică mutarea ulterioară a unui tag să schimbe pe ascuns codul executat. El nu stabilește dacă acel cod era sigur când a fost ales. O acțiune compromisă înainte de generarea fișierului poate fi fixată la fel de precis ca una legitimă, iar rulările viitoare vor păstra acel commit.

De aceea, prima includere și fiecare actualizare cer examinarea dependenței propuse, nu doar potrivirea dintre referință și fișier. Dacă o actualizare Dependabot schimbă commitul, acea diferență arată codul nou care ar urma să intre în procesul CI/CD. Protecția adăugată de lockfile devine utilă tocmai când această schimbare primește o decizie explicită înainte de integrare.

Citește și: