GitHub announced workflow dependency lockfiles on October 14. The preview covers GitHub Enterprise Cloud, including its data residency offering. An onboarded workflow runs commits recorded in .github/workflows/actions.lock; the gh actions-lock extension manages the file. Official announcement.
The useful review question is whether a dependency change becomes visible before the next run.
Start with a small workflow
My suggested adoption plan is to pick a workflow with a clear owner and a cheap failure path. Record its current behaviour, introduce locking, and inspect the resulting diff before extending the approach to deployment jobs.
Treat a generated file as something to review. Check which dependencies entered it, whether the selected revisions match your intent, and who will handle the next update. A clean generation command is evidence that a file was produced; it is not evidence that the dependency deserves trust.
Review the update path too
For this preview, GitHub says Dependabot updates the corresponding lock entry when it updates an action in an onboarded workflow. That makes the update pull request a useful place to check the reference and commit together.
During a trial, keep a short record:
- the workflow selected and the reason for choosing it;
- the dependency diff someone actually inspected;
- the check used to confirm the expected run;
- the owner of future updates and a recovery procedure.
These are proposed adoption checks, not results from a deployment I have performed. Verify availability for your account before planning a rollout. A preview announcement should lead to a bounded experiment with reviewable evidence.
Top comments (0)