GitHub Actions Lockfiles Fix the Moving Tag Problem You Have Been Ignoring

Most of us write uses: some-action@v4 and move on. The trouble is that a tag or branch can move after you have reviewed it, so tomorrow's run may execute different code with no change to your repository.

GitHub's answer, in public preview since 14 October, is a lockfile. The gh actions-lock extension generates .github/workflows/actions.lock, recording the exact commits for your actions and their transitive dependencies. Once a workflow is onboarded, Actions runs the recorded commits even if the tag has moved. You can onboard workflows one at a time, and a check mode flags stale lockfiles in CI.

Our view is that this is the right default. It is the same idea as a package lockfile, applied to the one place that holds your deploy keys. Dependabot regenerates the matching entry in the same pull request, so the upkeep cost is low.

Two cautions. Locking does not tell you whether a dependency is safe, only that it will not change underneath you, so review before you lock. And the Require lockfile policy is also in preview, which means admins can enforce it across an organisation.

If you run client deployments through Actions, pin first, then tidy up the rest of the pipeline.