Actions lockfiles are GA: green checks do not all prove the same thing
A pull request can leave a uses version looking unchanged while the code behind it moves. Tags point to commits, and that pointer can change. GitHub made workflow dependency lockfiles generally available on October 28. The pinning mechanism discussed during the preview still applies; the next useful question is what evidence each validation step actually provides when a team adopts it.
Readable references, recorded execution commits
.github/workflows/actions.lock connects action references with the commits selected to run. It is generated with gh actions-lock and is available on Free, Team, GitHub Enterprise Cloud and its data-residency offering. Workflows can be onboarded individually. That makes it possible to learn the review flow on one workflow before changing a repository's entire CI configuration. Review the generated file alongside the workflow changes rather than composing it by hand.
Consider an illustrative demo/build@v1 reference. It initially resolves to commit A and later moves to B. Resolving only the reference can select different code on a subsequent run; a lockfile selects the recorded commit. The illustration below shows this relationship, not a live repository test. There is also a reachability condition: a locked commit that is no longer reachable from its recorded upstream tag or branch can be rejected when the workflow runs.
What did the offline check establish?
The official extension distinguishes gh actions-lock --verify-local from gh actions-lock --verify. The first makes no network requests and checks coverage: whether uses references have lockfile entries. It fits a quick pre-commit check, but it does not establish the provenance of the recorded code. The online verify mode checks provenance, and the runner checks it again at job start. A green result means different things in those two contexts.
For example, a new action reference added in a parallel PR may lack a lockfile entry. Local coverage can catch that missing entry. Having every entry, however, does not itself prove provenance or establish that the code is safe. The second illustration summarizes the documented scopes; it is not a screenshot of checks executed for this article, and the CLI was not installed for this comparison.
Reusable workflows introduce a repository boundary
Transitive action dependencies are covered, but reusable workflow calls through jobs.<job_id>.uses are not pinned by the lockfile. Reference the reusable workflow by a full commit SHA. Its internal action dependencies belong to the lockfile in the repository where that workflow is defined, rather than to the caller's lockfile. This distinction matters when many application repositories share a central deployment workflow.
Imagine an application repository calling a platform repository's deployment workflow. Reviewing the application's actions.lock alone does not show what pins the platform workflow's actions use. The call SHA and the platform repository's dependency changes complete that picture. Runner images, inputs and secrets remain separate build inputs too: fixing the action commit does not freeze the whole environment or make every subsequent build identical.
Read the two files together in update PRs
When Dependabot proposes an action version update for an onboarded workflow, it regenerates the matching lockfile entry in the same PR. That puts a readable version change next to the underlying commit change. The --relock mode advances moved references and writes files; it serves a different purpose from read-only verification. Reviewing the changed implementation is still necessary before accepting the update.
Administrators can enforce adoption with Require lockfile, but a policy does not erase the reusable-workflow boundary. Starting with one workflow makes generation, review and online validation easier to understand before broad rollout. GA makes exact action dependencies easier to maintain. In the next PR, read a green check in terms of the evidence it supplies: entry coverage, provenance validation or an actual review of the selected code.