Workflow dependency lockfiles
Comments on “Workflow dependency lockfiles”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
GitHub has documented workflow dependency lockfiles for Actions. The gh actions-lock CLI extension writes .github/workflows/actions.lock, which pins every direct and transitive action to a commit, recording the source repository's owner and repo IDs so runs can detect a swapped repository. Locked commits must remain reachable from the recorded tag or branch. Reusable workflow calls are not pinned and still need full SHAs, and inputs, secrets and runner images are outside its scope. GitHub Enterprise Server is unsupported. Most claims come from GitHub's own documentation alone.
Why it ranked
No. 8 of 51 with a score of 0.67. The panel rated it highest on new information (0.88) and practical relevance (0.84), lowest on significance (0.59). Placed No. 8, No. 9 by score alone: the placement terms moved other stories past it.
- AI judgeJudge 2claude-haiku-5-5
- Product documentation for a new GitHub Actions lockfile feature. Highly practical for CI/CD builders and security-relevant, but it is official docs with no independent evidence, and it is partly promotional in tone.
- AI judgeJudge 3gpt-5.6-luna
- A concrete CI/CD supply-chain security feature with implementation details, transitive dependency coverage, repository identity checks, and migration guidance. It is highly actionable for teams using workflow automation, though limited mainly to that ecosystem.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.67total under rubric v2.3
- Significance0.59
- Reader interest0.72
- Audience breadth0.60
- Practical relevance0.84
- Substantiated0.69
- Technical depth0.74
- New information0.88
- Counts against: Promotional0.13
- Counts against: Overclaim0.12
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.59 | 0.50 | 0.67 | 0.59 | 0.17 | +0.24 | +0.141 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.61 | 0.72 | 0.82 | 0.72 | 0.21 | +0.26 | +0.186 |
| Audience breadthHow many people who build technology does it concern? | 0.47 | 0.67 | 0.67 | 0.60 | 0.20 | +0.13 | +0.078 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.85 | 0.80 | 0.86 | 0.84 | 0.06 | +0.22 | +0.184 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.57 | 0.67 | 0.82 | 0.69 | 0.25 | +0.05 | +0.034 |
| Technical depthHow technically substantive is it? | 0.80 | 0.72 | 0.70 | 0.74 | 0.10 | +0.05 | +0.037 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.91 | 0.85 | 0.88 | 0.88 | 0.06 | +0.05 | +0.044 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.08 | 0.20 | 0.12 | 0.13 | 0.12 | −0.19 | −0.025 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.12 | 0.15 | 0.08 | 0.12 | 0.07 | −0.11 | −0.013 |
| Sum of contributions | +0.667 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.667 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-11-08/8/"><img src="https://rubric.hrih.si/badge/2026-11-08/8.svg" alt="Ranked #8 on Rubric, 8 Nov 2026" width="231" height="28"></a>Claim check
Claim check: 1 matches source · 7 no source given. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenGeneralization
A workflow dependency lockfile pins a commit SHA to every action a repository's workflows depend on, including transitive dependencies.
The article gives no link or citation for it.
The article says “A workflow dependency lockfile pins a commit SHA to every action your workflows depend on, including transitive dependencies”
The source says No source to compare with.
No source givenGeneralization
The workflow dependency lockfile does not pin calls to reusable workflows (jobs.<job_id>.uses); these must be pinned by referencing the full commit SHA.
The article gives no link or citation for it.
The article says “It doesn't pin calls to reusable workflows (jobs.<job_id>.uses). To pin a reusable workflow, reference it by its full commit SHA”
The source says No source to compare with.
No source givenVersion
The lockfile is located at .github/workflows/actions.lock and is generated by gh actions-lock, a GitHub CLI extension.
The article gives no link or citation for it.
The article says “The lockfile is defined in a repository at .github/workflows/actions.lock. It's generated by gh actions-lock, a GitHub CLI extension”
The source says No source to compare with.
No source givenCausal conclusion
A locked commit that exists only in a fork, or is no longer reachable from the recorded branch or tag in the action's own repository, is rejected when the workflow runs.
The article gives no link or citation for it.
The article says “A commit that exists only in a fork, or that's no longer reachable from that branch or tag, is rejected when the workflow runs”
The source says No source to compare with.
No source givenGeneralization
A reusable workflow's dependencies are covered by the lockfile of the repository where it is defined, not by the calling repository's lockfile.
The article gives no link or citation for it.
The article says “A reusable workflow's dependencies are covered by the lockfile of the repository where it's defined, not by the lockfile of the repository that calls it”
The source says No source to compare with.
No source givenCausal conclusion
GitHub Actions uses the recorded owner_id and repo_id to confirm at run time that the repository behind the name is still the one that was locked.
The article gives no link or citation for it.
The article says “GitHub Actions uses these to confirm at run time that the repository behind the name is still the one you locked”
The source says No source to compare with.
No source givenGeneralization
For repositories that adopt a lockfile, SHA pinning within workflow files is no longer necessary, because the lockfile supports transitive dependencies, makes workflow files easier to read and records source repository identity.
The article gives no link or citation for it.
The article says “For repositories that adopt a lockfile, SHA pinning within workflow files is no longer necessary. The lockfile is the better option”
The source says No source to compare with.
Matches sourceGeneralization
A lockfile satisfies the 'Require actions to be pinned to a full-length commit SHA' policy for workflows onboarded to it.
The cited source says the same thing.
The article says “A lockfile also satisfies the separate Require actions to be pinned to a full-length commit SHA policy for workflows that are onboarded to it”
The source says “A lockfile satisfies the SHA-pinning requirement for workflows that are onboarded to a lockfile”
Source cited by the article: docs.github.com/en/actions/how-tos/administer/control-workflow-execution
Also covered by
Elsewhere
Elsewhere: HN —
Recorded for context only, checked 8 Nov 2026, 05:46 UTC. It played no part in the ranking.