GitHub Actions workflow lockfiles enter public preview for every plan

A workflow that references actions/checkout@v4 reruns a different piece of code the day somebody with push access to the v4 tag moves it. GitHub opened a public preview on 14 October for workflow dependency lockfiles that keep the reference the author wrote and run the commit the maintainer recorded.

The preview is available on GitHub Enterprise Cloud, Enterprise Cloud with data residency, Team and Free plans, GitHub says, after an editor's note on the day of the announcement widened the list. It covers actions, their transitive dependencies, and the reusable workflow dependencies a workflow calls.

What the lockfile holds, and how it is produced

Nothing in a repository is lifted in place. The lockfile lives alongside the workflows at .github/workflows/actions.lock, and GitHub ships a gh actions-lock extension for the GitHub CLI to create and maintain it. The extension writes a reviewable commit for every action and reusable workflow a workflow uses, including anything a called action pulls in. Onboarding is per workflow, so a repository can lock one pipeline at a time and leave the others untouched. Once a workflow is onboarded, Actions requires every one of its dependencies to be in the lockfile and runs the recorded commit even if the tag or branch now points somewhere else.

The policy and the Dependabot path

The Require lockfile policy is in public preview too. Enterprise, organisation and repository administrators can require every workflow to use a lockfile across their scope. For teams running CI on the lockfile itself, the extension checks whether a committed lockfile is still current without modifying any files, a form a CI step can run on a pull request.

Dependabot carries the update path. GitHub says that when Dependabot opens a version update for an action in a workflow that is already onboarded, it regenerates the matching lockfile entry inside the same pull request. The updated reference and its locked commit stay together with no extra configuration, which is the piece that keeps a locked repository from falling behind.

The changelog is explicit that locking is not a safety judgement. GitHub writes that locking does not determine whether the dependency itself is safe, and reviewers should still check a dependency before locking it. The lockfile stops a moved tag from quietly swapping the code; a maintainer the team has already decided to trust is still trusted.

GitHub thanks four named community members in the entry, Andrew Nesbitt, François Proulx, Jesse Houwing and William Woodruff, for a year of iteration on the design.

Source

GitHub Changelog, GitHub Actions workflow lockfiles in public preview. Extension and setup documentation at the gh-actions-lock repository.