A moved tag can no longer change what an onboarded GitHub Actions workflow runs
GitHub put workflow lockfiles in public preview, so onboarded Actions runs use the commits recorded in actions.lock even if a tag or branch moves. The lock does not assess whether the action is safe; that review stays with the team.
The Engineer · Build desk
Who the lockfile reaches: onboarded workflows run recorded commits even if a tag moves; the lock does not assess action safety; reviewers confirm repositories and commits; owners regenerate stale locks; reusable workflows stay in inventory; the guide advises one workflow first.
- capability Onboarded workflows Runs use the commits recorded in the lockfile even if a tag or branch moves, claim 3
- constraint Workflow dependencies The lock records which commit each resolves to; it does not assess whether the action is safe, claim 6
- cost Reviewers Should confirm every resolved repository was intended and each commit matches the version meant, claim 15
- cost Lock owner Regenerates the lock when the stale-lock check fails and reviews which references changed, claim 18
- exposure Reusable workflows Covered by the lockfile where defined; locking the caller leaves their dependencies in your inventory, claim 8
- decision Teams starting onboarding Guide advises one pull-request or non-production workflow first, then release or deployment automation, claim 14
| Who | How | Kind | Claim |
|---|---|---|---|
| Onboarded workflows | Runs use the commits recorded in the lockfile even if a tag or branch moves | capability | 3 |
| Workflow dependencies | The lock records which commit each resolves to; it does not assess whether the action is safe | constraint | 6 |
| Reviewers | Should confirm every resolved repository was intended and each commit matches the version meant | cost | 15 |
| Lock owner | Regenerates the lock when the stale-lock check fails and reviews which references changed | cost | 18 |
| Reusable workflows | Covered by the lockfile where defined; locking the caller leaves their dependencies in your inventory | exposure | 8 |
| Teams starting onboarding | Guide advises one pull-request or non-production workflow first, then release or deployment automation | decision | 14 |
What happened
- The preview covers Free, Team and eligible Enterprise Cloud plans, and the gh actions-lock extension generates the file at .github/workflows/actions.lock.
- The lock records direct actions, transitive action dependencies and reusable-workflow dependencies, so a workflow's whole resolved set sits in one file.
- GitHub's October 14 announcement also describes gradual onboarding, policy enforcement and Dependabot updates.
Why it matters
- constraint The lock fixes which commit runs but does not check whether that commit is good, so a bad commit approved at generation time is pinned as firmly as a good one.
- cost Each adopting team takes on a generated file to keep current: a CI staleness job, an owner who regenerates it, and a lock diff to review with every action update.
- decision Teams must pick an onboarding order. The guide advises one pull-request or non-production workflow first, with release and deploy automation next, before any repository-wide requirement.
- exposure A reusable workflow is covered by the lockfile in the repository that defines it, so a caller's lock leaves a separate repository's dependencies on the inventory.
The dev.to guide frames the problem as a gap between the commit a team reviewed and the commit a later run executes [16]. Pinning every action to a full SHA by hand narrows that gap, but the guide says transitive dependencies and reusable workflow calls are easy to miss that way [12].
The lockfile changes where the pin lives. The workflow keeps a readable ref such as owner/action@v3, and the generated lock records the exact commit [7]. Because the lock also covers transitive dependencies, a reviewer sees the resolved set instead of trusting each top-level tag [17]. Each dependency entry holds the reference, the resolved commit and the repository identity [9].
The guide is direct about the limit: the lock records which commit a dependency resolves to, and it does not assess whether the action is safe [6]. A malicious commit that a reviewer waves through is recorded and executed as faithfully as a good one [3]. In our view, the control point moves from every run to every lock diff.
That puts the weight on whoever reads the diff. The guide's checklist is to confirm that each resolved repository is one the team meant to use and that each commit matches the version it meant to adopt [15].
The running cost is small but real. The file is generated, and the guide warns against editing it by hand, because an altered entry can no longer be trusted to match what the generator resolved [13]. To catch drift, the extension can check whether the lockfile is current without modifying it, which suits a CI job [10]. When that check fails, the owner regenerates the lock, reviews which references changed, and commits the update with the workflow change [18].
After onboarding, the guide says missing entries should fail visibly instead of falling back to a floating tag [11]. We'd test that on the first workflow before relying on it.
The guide lists policy enforcement and Dependabot updates among the features in GitHub's October 14 announcement but does not detail how either is configured [5].
What to watch
- Whether GitHub documents how policy enforcement is configured, and whether an organization can require onboarding across repositories.
- How Dependabot updates to an onboarded action show up in a pull request, and whether the lock diff is reviewable at that point.
- Whether the preview adds any check on the content or provenance of a locked commit, which the current description does not include.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence45
- Adoption
- Insufficient
- Hype gap−10
- Incentives
- Insufficient
- Confidence50
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
GitHub Actions workflow dependency lockfiles are in public preview for Free, Team, and eligible Enterprise Cloud plans.
- [2]
The GitHub CLI extension gh actions-lock generates .github/workflows/actions.lock.
- [3]
GitHub says an onboarded workflow must have its dependencies represented in the lockfile, and runs use the recorded commits even if a tag or branch moves.
- [4]
The file records direct actions, transitive action dependencies, and reusable-workflow dependencies.
- [5]
GitHub's October 14 announcement also describes gradual onboarding, stale-lock checks, policy enforcement, and Dependabot updates.
- [6]
The lock records which commit a workflow dependency resolves to; it does not assess whether the action is safe.
- [7]
The workflow can retain a human-meaningful ref while the generated lock records the exact commit to use.
- [8]
A reusable workflow is covered by the lockfile in the repository where it is defined; locking the caller's repository does not make a separate reusable-workflow repository's dependencies disappear from your inventory.
- [9]
The lockfile is generated by gh actions-lock and should not be edited manually; its dependency section records the reference, resolved commit, and repository identity.
- [10]
The extension can check whether a lockfile is current without modifying it, which makes that check suitable for CI.
- [11]
Once a workflow is covered by the lockfile, missing entries should fail visibly rather than falling back to a floating tag.
- [12]
Pinning every action by hand to a full commit SHA narrows the gap, but it is easy to miss transitive dependencies and reusable workflow calls.
- [13]
A manually altered lock entry can no longer be trusted to match what the generator resolved.
- [14]
The guide advises against starting with a repository-wide requirement and suggests beginning with one workflow that runs on pull requests or deploys a non-production environment, then adding higher-impact paths such as release or deployment automation.
- [15]
Reviewers should confirm that every resolved repository is one the team intended to use and that the commit corresponds to the version it meant to adopt.
- [16]
A workflow reference can keep saying uses: vendor/build-action@v3 while the code behind v3 changes, leaving a gap between the commit a team reviewed and the commit a later workflow run executes; a tag is a name that can be moved.
- [17]
The lockfile captures transitive dependencies, so a review can see the resolved set rather than relying on each top-level action tag.
- [18]
When the stale-lock check fails, the owner should regenerate the lock, review which references changed, and commit the update with the corresponding workflow change.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toLock GitHub Actions dependencies to reviewed commits with workflow lockfiles
1 article · October 14, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.