Once a workflow has an actions.lock entry, a moved tag no longer changes what GitHub Actions runs
GitHub's Actions lockfile, in public preview since October 2026, pins each action in a workflow to a commit SHA, DEV Community reports. A pinned commit that vanishes fails the run, so teams trade silent drift for hard errors.
The Engineer · Build desk
For 10 action updates, the count falls from 10 pull requests to one lockfile update, with a diff showing all the changes.
| Measure | Value | As of | Claim |
|---|---|---|---|
| Pull requests | 10 per 10 updates | 16 | |
| Lockfile update | 1 per 10 updates | 16 |
What happened
- At run time GitHub Actions reads the lockfile and executes the recorded commits, ignoring tag movements, while the workflow file keeps its readable tags.
- The lockfile sits at .github/workflows/actions.lock and maps each action reference to a resolved commit SHA and an integrity value.
- The gh actions-lock generate command walks the dependency graph and recursively resolves composite actions, so nested actions get pinned too.
- Administrators can set a Require lockfile policy at the enterprise, organization or repository level.
Why it matters
- What it costs cost A pinned commit or action repository that disappears upstream becomes a failed build on your side, because lockfiles keep no cache and have no automatic fallback.
- What it limits constraint Under the Require lockfile policy a stale lockfile fails the run and manual runs cannot bypass it, so any workflow edit that adds an action has to regenerate the lockfile first.
- Who has to decide decision Enforcement is per workflow, so a team can lock the workflows with write permissions or secrets first and defer the rest.
- Who's exposed exposure The lockfile fixes what runs but does not vet the commit it recorded, so the review of each update diff is the control that matters.
A tag is a Git reference, and references move. If v4 points at one commit today and another tomorrow, the workflow runs different code with no change to the repository [1]. A review of the workflow file has nothing to see. The DEV Community post lists four routes to that outcome: maintainer account takeover, force-pushed tags after code review, compromised release automation, and transitive dependencies in composite actions [18].
Dependabot already pins actions to full SHAs in workflow files, but each SHA update then needs a pull request and a manual review [2]. The lockfile moves the pin out of the workflow definition [3]. The post's example is ten action updates arriving as one lockfile diff in place of ten pull requests [16]. That count is illustrative. It transfers only if the updates land together, and the person reviewing the single diff still has to read ten upstream changes. The post adds that Dependabot can update lockfiles automatically [17].
The hard failure is the design choice to look at. The post defends it: a deleted commit signals either repository corruption or an attempt to hide malicious code, and failing loudly is safer than falling back to a mutable reference [11]. We think that is the right tradeoff where a workflow holds secrets or write permissions. It is a harsh one for a disposable build that only needs to go green.
The post is the only source here. Its sample shows an integrity field beside each resolved SHA, but it does not say what the field hashes or when GitHub checks it [5].
What to watch
- GitHub's own documentation for the preview: what the integrity field hashes and when the runner verifies it.
- Whether Dependabot's lockfile updates group several action bumps into one pull request, since the ten-to-one example depends on it.
- How the Require lockfile policy treats an emergency manual run when the lockfile is stale.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence30
- Adoption
- Not scored
- Hype gap+20
- Incentives
- Not scored
- Confidence35
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Tags are Git references that can move; if v4 points to one commit today and another tomorrow, the workflow executes different code without any change to the repository.
- [2]
Dependabot can pin actions to full SHAs in workflow files, but every SHA update then requires a pull request and manual review.
- [3]
Lockfiles separate the pinning mechanism from the workflow definition.
- [4]
GitHub Actions workflow lockfiles entered public preview in October 2026 for Enterprise Cloud, Team and Free plans.
- [5]
The lockfile lives at .github/workflows/actions.lock and maps each action reference to a resolved commit SHA and an integrity value (shown as sha256-...).
- [6]
When a workflow runs, GitHub Actions reads the lockfile and executes the recorded commits, ignoring tag movements; the workflow file still uses human-readable tags.
- [7]
Once a workflow is locked, GitHub Actions requires lockfile entries for all its dependencies, and missing entries cause the workflow to fail.
- [8]
The gh actions-lock generate command parses workflow YAML for uses statements, fetches each action's action.yml, recursively resolves composite action dependencies and records commit SHAs for the entire tree.
- [9]
Reusable workflows are also locked: the lockfile pins the reusable workflow's commit and any actions it uses.
- [10]
Lockfiles do not create local caches; if a pinned commit is deleted or force-pushed, the workflow fails with a hard error because actions are fetched from the repository at runtime.
- [11]
The post calls the hard error intentional: a deleted commit signals either repository corruption or an attempt to hide malicious code, and failing loudly is safer than falling back to a mutable reference.
- [12]
If an action repository is deleted entirely, workflows fail until the dependency is removed or pointed to a fork; there is no automatic fallback.
- [13]
A 'Require lockfile' policy lets administrators mandate lockfiles at the enterprise, organization or repository level.
- [14]
With the policy enabled, workflows without lockfiles fail, workflows with stale lockfiles (missing entries for new actions) fail, and manual workflow runs cannot bypass the requirement.
- [15]
Policy enforcement works at the workflow level, so high-risk workflows (those with write permissions or access to secrets) can be onboarded first.
- [16]
Lockfiles batch updates: instead of 10 pull requests for 10 action updates, there is one lockfile update with a diff showing all changes.
- [17]
Dependabot can update lockfiles automatically.
- [18]
The post lists the attack surface as maintainer account takeover, force-pushed tags after code review, compromised release automation, and transitive dependencies in composite actions.
- [19]
If any transitive dependency is compromised, the lockfile prevents execution until the user explicitly updates and reviews the 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.
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.