# Pinning GHA actions/shared workflows to commits

**URL:** <https://forum.ansible.com/t/pinning-gha-actions-shared-workflows-to-commits/46118>\
**Category:** Collection Development\
**Tags:** infra-and-security, github, security, antsibull-nox, ci\
**Created:** [August 1, 2026, 9:19pm UTC](https://forum.ansible.com/t/pinning-gha-actions-shared-workflows-to-commits/46118 "2026-08-01T21:19:21Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [August 1, 2026, 9:19pm UTC](https://forum.ansible.com/t/pinning-gha-actions-shared-workflows-to-commits/46118/1 "2026-08-01T21:19:21Z")

</div>

There’s currently a push to pin GHA actions and shared workflows to commit hashes (to thwart certain types of supply chain attacks). While doing that for several repos, I found several (potential) problems and solutions.

First, here’s a collection of commands that pin certain actions:

```auto
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: actions\/checkout@.*/ uses: actions\/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: actions\/configure-pages@.*/ uses: actions\/configure-pages@45bfe0192ca1faeb007ade9deae92b16b8254a0d # v6.0.0/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: actions\/deploy-pages@.*/ uses: actions\/deploy-pages@cd2ce8fcbc39b97be8ca5fce6e763baed58fa128 # v5.0.0/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: actions\/download-artifact@.*/ uses: actions\/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: actions\/github-script@.*/ uses: actions\/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: actions\/upload-artifact@.*/ uses: actions\/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: actions\/upload-pages-artifact@.*/ uses: actions\/upload-pages-artifact@fc324d3547104276b827a68afc52ff2a11cc49c9 # v5.0.0/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: actions\/setup-node@.*/ uses: actions\/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: actions\/setup-python@.*/ uses: actions\/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: codecov\/codecov-action@.*/ uses: codecov\/codecov-action@fb8b3582c8e4def4969c97caa2f19720cb33a72f # v7.0.0/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: peter-evans\/create-or-update-comment@.*/ uses: peter-evans\/create-or-update-comment@e8674b075228eee787fea43ef493e45ece1004c9 # v5.0.0/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: peter-evans\/find-comment@.*/ uses: peter-evans\/find-comment@b30e6a3c0ed37e7c023ccd3f1db5c6c0b0c23aad # v4.0.0/g'; done
for i in $(git grep -l ' uses:'); do sed -i $i -e 's/ uses: wntrblm\/nox@.*/ uses: wntrblm\/nox@3284968a16fa5bd7fc0cc64a69a531404ccb4756 # 2026.07.11/g'; done

```

This could be useful for some to quickly pin some action uses. Obviously the versions used in these commands will be outdated soon, but at least for now they are a helpful starting point 🙂

Then there’s a new GitHub Actions feature that’s very useful for (shared) workflows that want to reference actions or other shared workflows in the same repository. Using [the new `uses: $/...` syntax](https://github.blog/changelog/2026-07-30-reference-same-repository-actions-with-self-repository-syntax/), it is now possible to make this work with pinning without having to use ugly workarounds. Using this syntax makes sure that the referenced action/workflow uses the same commit hash as the caller. I’ve implemented this in [antsibull-nox](https://github.com/ansible-community/antsibull-nox/pull/237) and [github-docs-build](https://github.com/ansible-community/github-docs-build/pull/123), where this caused problems especially with proper testing for a long time.

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [August 1, 2026, 9:23pm UTC](https://forum.ansible.com/t/pinning-gha-actions-shared-workflows-to-commits/46118/2 "2026-08-01T21:23:00Z")

</div>

There’s also a problem, which I wanted to describe in its own comment. Namely, we have a set of small actions:

- [GitHub - ansible-community/github-action-run-nox: Convenience GitHub Action to run nox, to be combined with the wntrblm/nox action · GitHub](https://github.com/ansible-community/github-action-run-nox/)
- ~~[GitHub - ansible-community/github-action-test-galaxy-import: GitHub Action for testing Galaxy import of an Ansible collection · GitHub](https://github.com/ansible-community/github-action-test-galaxy-import/)~~ (going to be archived)
- ~~[GitHub - ansible-community/github-action-build-collection: GitHub Action for building Ansible collections · GitHub](https://github.com/ansible-community/github-action-build-collection/)~~ (going to be archived)

that don’t have proper releases (we use them from their `v1` or simply `main` branch), and for these pinning doesn’t work well, since Dependabot won’t update the pin since there are no releases. (At least to my knowledge, but maybe I’m wrong?)

As far as I know, the only way to be able to pin these would be to regularly create releases. But creating releases means more effort, also since now there will be more frequent updates (due to pinned versions of their dependencies; so far bumps only happened when actions released new major versions, now also for minor and bugfix releases), and thus we should also release these actions and shared workflows more frequently. This creates some extra work (and policy decisions, like how often should these be released?).

What do people think about this?

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [August 1, 2026, 9:27pm UTC](https://forum.ansible.com/t/pinning-gha-actions-shared-workflows-to-commits/46118/3 "2026-08-01T21:27:18Z")

</div>

And a third problem are shared workflows / actions such as antsibull-nox: if ansible-ocre devel / milestone changes for example their supported Python versions, antsibull-nox gets a little update so that collections using it don’t suddenly have a broken CI when trying to run tests for no longer supported Python versions. If you now pin your antsibull-nox action or shared workflow to a specific version, we now have to do two things:

1. Make sure to release a new version of antsibull-nox as soon as possible;
2. Update the pin as soon as possible.

Until now, when sticking to `@main` or `@stable`, only required a new commit to antsibull-nox (for `@main`) or a new release (for `@stable`), and not updating the collections’ pin as well. This generates more friction for collection development.

Obviously we can work around this by making antsibull-nox in CI fetch some data from the repository, and lets that data overwrite certain aspects in the release that is now used. But that goes kind of against pinning.

Alternatively, antsibull-nox could stop using the HEAD of branches of ansible-core (`stable-2.x`, `milestone`, and `devel` branches). But that also has some disadvantages.

So this is also something that we - as a community - need to look at and discuss.

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [August 17, 2026, 6:42pm UTC](https://forum.ansible.com/t/pinning-gha-actions-shared-workflows-to-commits/46118/4 "2026-08-17T18:42:40Z")

</div>

6 posts were split to a new topic: [Deprecate build collection and test import to Galaxy GitHub Actions and shared workflows](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184)

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [August 17, 2026, 6:46pm UTC](https://forum.ansible.com/t/pinning-gha-actions-shared-workflows-to-commits/46118/5 "2026-08-17T18:46:46Z")

</div>

[@SteeringCommittee](https://forum.ansible.com/groups/steeringcommittee) pinging you since I think this thread raises some important questions regarding pinning GitHub Actions, with so far zero feedback to the main questions.

---

<div class="post-metadata">

**Author:** ![nitzmahone](https://avatars.discourse-cdn.com/v4/letter/n/c5a1d2/32.png) [@nitzmahone](https://forum.ansible.com/u/nitzmahone)\
**Post date:** [August 17, 2026, 11:11pm UTC](https://forum.ansible.com/t/pinning-gha-actions-shared-workflows-to-commits/46118/6 "2026-08-17T23:11:19Z")

</div>

Just wanted to make sure everyone’s aware that GH is currently developing an actions lockfile feature to aid with this problem. Hopefully can avoid reinventing too many wheels, and IIUC they’re still in active development and looking for trial/feedback…

More info:

- [Locked Dependencies for GitHub Actions Workflows [Public Preview] · Issue #1253 · github/roadmap · GitHub](https://github.com/github/roadmap/issues/1253)
- [GitHub - github/actions-lockfile: The authoritative definition of the GitHub Actions dependency lockfile format, plus a Go parser for auditing and verifying the action pins in use across a repo's workflows. · GitHub](https://github.com/github/actions-lockfile)
- [GitHub - github/gh-actions-lock: A gh CLI extension that generates and verifies the GitHub Actions dependency lockfile, pinning every action your workflows use to an exact commit. · GitHub](https://github.com/github/gh-actions-lock)

---

<div class="post-metadata">

**Author:** ![webknjaz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/webknjaz/32/5183_2.png) [@webknjaz](https://forum.ansible.com/u/webknjaz)\
**Post date:** [August 18, 2026, 9:10am UTC](https://forum.ansible.com/t/pinning-gha-actions-shared-workflows-to-commits/46118/7 "2026-08-18T09:10:05Z")

</div>

Last time I checked (around June / May I think?), this was definitely in _active_ development and didn’t work with my creative (ab)use of reusable workflows. Although I did get to give some early feedback like the fact that I didn’t like having the lockfile structure within the workflow files and wanted this in standalone files. I saw some other people voicing the same concern too. Now it’s separate indeed. Need to re-test it again now…