[kylebarron]

Note

This PR was written by Claude (Claude Code), not by @kylebarron.

Adopts GitHub Actions workflow lockfiles, now generally available. It records the commit for every action in a separate file, so the workflow files keep human-readable tags instead of SHA pins.

What changes

• .github/workflows/actions.lock, generated by the gh actions-lock extension (v0.4.1). It records the commit for every action, including those used inside composite actions, across the 8 workflows. Actions runs that commit even if the tag later moves, and checks the source repo's owner and repo IDs at job start.
• Readable tags. The tool rewrote 9 SHA pins to full release tags (e.g. Swatinem/rust-cache@d1527c8… to @v2.9.3). Each resolves to the same commit as before.
• Floating tags narrowed. 38 refs like actions/checkout@v7 became the highest matching full release tag (@v7.0.1). Full tags rarely move, so the locked commit stays valid longer.
• dtolnay/rust-toolchain@stable to @master with toolchain: stable (separate commit). dtolnay force-pushes the stable branch every time master moves, so a locked stable commit drops out of upstream history and the runner rejects it at job start. master only fast-forwards; the installed toolchain is unchanged. The existing SHA pin of stable was already unreachable upstream, which is what made the lockfile tool fail.
• New Actions lockfile workflow that runs gh actions-lock --verify, so CI fails if a uses: has no lockfile entry or a pin no longer verifies upstream. Adapted from the extension's own verify-lockfile.yml.

Dependabot already updates github-actions here. For an onboarded workflow, a Dependabot bump also regenerates the action's lockfile entry in the same PR.

Updating the lockfile

gh extension install github/gh-actions-lock
gh actions-lock    # after adding a workflow or changing any `uses:`

Never edit actions.lock by hand.

Not covered

• Required check. Verify actions lockfile isn't a required status check. Add it in branch protection if it should block merges.
• "Require lockfile" policy. A repository setting that rejects workflows without a lockfile. Not turned on.
• pypa/gh-action-pypi-publish runs a Docker action it generates at run time under ./.github/.tmp/. The tool reports it as a workspace-local action it can't follow. That's a warning, not an error, because the generated action uses no other actions (gh-actions-lock#128). The pypi-publish action itself is locked.
• ytanikin/pr-conventional-commits builds a Docker image from its own Dockerfile. The action is locked, but its base image isn't pinned by digest upstream.
• The gh extension install step in the verify workflow is pinned to a tag, not covered by the lockfile.

Verification

gh actions-lock --verify passes locally: "All 8 workflows valid".

🤖 Written by Claude Code

[kylebarron]

✅