GitHub Actions dostáva lockfile: pohyb tagu už nemusí zmeniť kód workflowu

GitHub 14. októbra otvoril verejnú predbežnú verziu workflow lockfiles pre plány Free, Team aj Enterprise Cloud. Rieši situáciu, keď workflow odkazuje na tag alebo vetvu cudzej akcie. Takýto odkaz sa môže posunúť, takže nasledujúci beh vykoná iný kód aj bez zmeny v používateľovom repozitári.

Lockfile zachová čitateľné odkazy v konfigurácii, ale zaznamená presné commity, ktoré sa majú použiť. Vývojár tak môže posúdiť aktualizáciu ako konkrétnu zmenu závislosti. Je to podobný princíp, aký pozná z uzamykania balíkov aplikácie, prenesený do automatizovaných buildov a kontrol.

Rozšírenie GitHub CLI s názvom gh actions-lock vytvára súbor .github/workflows/actions.lock. Podľa oznámenia zachytáva akcie, ich tranzitívne závislosti aj závislosti opakovane použiteľných workflowov. Zavádzanie môže prebiehať postupne po jednotlivých workflowoch.

Keď je workflow zapojený do uzamykania, jeho závislosti musia mať záznam v lockfile a GitHub používa zaznamenaný commit. Nástroj vie tiež kontrolovať zastaraný stav bez prepisovania súborov. Správcovia dostávajú predbežnú politiku Require lockfile, ktorou môžu používanie vynútiť na úrovni repozitára, organizácie alebo podniku.

Dependabot pri aktualizácii akcie v už zapojenom workflowe obnoví zodpovedajúci záznam v rovnakom pull requeste. Referencia vo workflowe a uzamknutý commit tak môžu prejsť jednou kontrolou. Pri ručných úpravách treba rovnakú zhodu udržiavať vlastným postupom.

Lockfile však nerozhoduje, či je uzamknutý kód bezpečný. Ak tím schváli škodlivú verziu, presné opakovanie ju neopraví. Pri prvom zavedení je preto dôležitá kontrola vybraných commitov a potom pravidelné aktualizácie. Praktický pilot môže začať jedným buildom: uložiť vygenerovaný súbor, preskúmať zmenu a overiť ďalší beh. Hlavným prínosom je dohľadateľnosť toho, čo automatizácia skutočne vykonáva.

Pre tímy s veľkým počtom repozitárov má postupné zapájanie praktickú výhodu. Najprv môžu preskúmať workflow s menším počtom závislostí a odhaliť vlastné výnimky. Až potom má zmysel rozšíriť povinnú politiku na ďalšie projekty. Súčasťou prevádzky má byť aj dohoda, kto kontroluje zmeny lockfile a ako sa rieši aktualizácia, ktorá mení správanie buildu alebo vyžaduje novšie prostredie bežiaceho runnera.