# GitHub Action workflow lockfiles

**URL:** <https://forum.ansible.com/t/github-action-workflow-lockfiles/46613>\
**Category:** Project Discussions\
**Tags:** infra-and-security, collections\
**Created:** [November 6, 2026, 10:50am UTC](https://forum.ansible.com/t/github-action-workflow-lockfiles/46613 "2026-11-06T10:50:10Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![oranod](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/oranod/32/1434_2.png) [@oranod](https://forum.ansible.com/u/oranod)\
**Post date:** [November 6, 2026, 10:50am UTC](https://forum.ansible.com/t/github-action-workflow-lockfiles/46613/1 "2026-11-06T10:50:10Z")

</div>

GitHub recently announced [workflow lockfiles](https://github.blog/changelog/2026-10-28-github-actions-workflow-lockfiles-are-generally-available/) that can replace SHA pinning for actions.

Here is what a workflow lockfile might look like:

```yaml
# .github/workflows/test.yml
- uses: actions/checkout@v7.0.1

```

```yaml
# .github/workflows/test.yml.lock
actions/checkout@v7.0.1:
resolved: 3d3c42e5aac5ba805825da76410c181273ba90b1
integrity: sha256:a12b3c4d5e6f...

```

For Ansible collections this seems like a solid improvement over SHA pinning.

Firstly, generated lockfiles remove the error-prone manual process. You often need to go to the action repo, find the release, and then manually copy the commit SHA.

In some cases I’ve observed AI-assisted pinning that generated hallucinated SHAs that broke workflows, which meant that the CI checks didn’t run on PRs. Eventually the missing checks were noticed but, in the meantime, changes were slipping past those gates.

There’s also improved tooling with `gh workflow lock` that includes cryptographic integrity verification, human-readable semantic versions, and automated Dependabot updates.

Integrity verification is the main security benefit over SHA pinning. Lockfiles include `sha256` checksums that GitHub validates on every workflow run. Workflow execution fails if there are mismatches between the declared version, resolved SHA, and integrity hash.

One downside is that GitHub generates one `.yml.lock` file per workflow file. There is no repo-wide lockfile option. So any collections with multiple workflows will need to have multiple lockfiles. Dependabot can take care of the maintenance but lots of lockfiles will introduce more “visual clutter” in the repo.

What do others think about GHA workflow lockfiles? Is anyone using them already and have insights or tips they want to share?

---

<div class="post-metadata">

**Author:** ![liammiller](https://avatars.discourse-cdn.com/v4/letter/l/6bbea6/32.png) [@liammiller](https://forum.ansible.com/u/liammiller)\
**Post date:** [November 6, 2026, 11:00am UTC](https://forum.ansible.com/t/github-action-workflow-lockfiles/46613/2 "2026-11-06T11:00:42Z")

</div>

The hallucinated-SHA problem you describe is the part that resonates most for me — a pin that looks legitimate but points nowhere silently defeats the gate. That said, I’m skeptical of framing integrity hashes as a big step up from SHA pinning. Both anchor to a commit; the checksum mainly catches a mangled lockfile, not a compromised upstream tag, since the lock just records what was resolved at generation time. The per-workflow lockfile point is the real friction — a repo with six workflows means six files to review in diffs. Does `gh workflow lock` give any way to verify all of them at once, or is that still a per-file loop?