GitHub Actions lockfiles enter preview: what changes for build review?

GitHub announced public preview availability for Actions workflow dependency lockfiles on October 14. Its announcement lists Free, Team and Enterprise Cloud plans, including Enterprise Cloud with data residency. The feature lets a workflow keep tag or branch references while executing recorded commits.

GitHub also stresses a boundary: recording a dependency does not establish that its code is safe. The development matters because it separates two decisions that are easy to blur: which code was selected, and whether that code deserves to run. This is a preview, not a finished feature whose behavior should be assumed permanent.

GitHub's documentation explains that a tag or branch can point to a different commit later. The lockfile lives at .github/workflows/actions.lock and is generated by the gh actions-lock CLI extension. Once a workflow is onboarded, its action dependencies must have lockfile entries, and execution uses the recorded commits.

The documented coverage includes transitive action dependencies. Reusable workflow calls have an important boundary: dependencies inside a called reusable workflow are covered by the lockfile in the repository that defines that workflow. Do not treat one repository's lockfile as a complete inventory of everything another repository runs.

For a build owner, the practical question becomes more specific than whether a workflow file changed. Ask which dependency record changed, who reviewed that change and what evidence shows the resulting build still behaves as intended. That is an operational interpretation, not a guarantee from the feature.

A sensible pilot can start with a nonproduction workflow and an explicit record of what is being tested. The following checklist is an editorial planning approach, not a mandatory GitHub procedure:

The extension's current README documents gh actions-lock --verify as a check that does not write changes. It distinguishes that from --verify-local, an offline check that only establishes whether references have entries; the README explicitly says that local check does not establish trustworthiness.

The same README says normal runs keep recorded pins rather than advancing moving branch or partial-version references. Refreshing them uses a separate relocking operation. It warns that the pre-1.0 extension, flags and file format may change, and says GitHub Enterprise Server is unsupported.

That distinction suggests a useful maintenance rule: checking a record and choosing a newer dependency should be separately visible activities. If an automated check fails, investigate the reason instead of treating a refresh as a universal repair. This article reports the tooling; it does not install it or alter any repository's access policies.

GitHub's Dependabot documentation says that, for workflows already onboarded to a lockfile, an action version-update pull request also regenerates the matching lockfile entry. The updated workflow reference and recorded commit can therefore be inspected in the same proposed change.

The surrounding review still matters. Consider a hypothetical team whose nightly report depends on a third-party action. A proposed update can be internally consistent yet change the report's behavior. That team still needs a representative test and a reviewer who understands the output. This is an illustration, not a customer incident or measured result.

The useful outcome is an explainable sequence: a dependency was proposed, its selected commit was recorded, the change was reviewed, and relevant checks were examined. Repeatability makes that sequence easier to inspect. It does not replace the judgment at each step.