Correct action version comments that disagreed with their SHAs - #37
Merged
Conversation
publish.yml pinned:
actions/upload-artifact@043fb46d... # v4.5.0 <- SHA is v7.0.1
actions/download-artifact@3e5f45b2... # v4.1.4 <- SHA is v8.0.1
Confirmed against the upstream tag lists. The SHAs are correct and were verified
when they landed; the COMMENTS were not updated with them.
My fault. Rebuilding those Dependabot branches on the RC replaced the pinned SHA
and left the trailing comment untouched, so every reader of this workflow has
since been told it runs v4.5.0 while it actually runs v7.0.1 - a three-major gap
in what a reviewer thinks they are approving.
The comment is the ONLY human-readable part of a SHA pin. A wrong one is worse
than none: it looks like provenance and is misinformation.
It also explains why Dependabot #27 and #28 CONFLICT. Dependabot reads the
comment, believes the pin is v4.5.0, and proposes bumping to the SHA that is
already there. With the comments corrected those PRs are redundant rather than
conflicting - they propose exactly what is already pinned.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The first commit on this branch fixed two pin comments. Auditing every pin against
the real upstream tag lists found five, not two:
actions/checkout@3d3c42e5 said v4.2.2 really v7.0.1 (ci.yml AND publish.yml)
actions/upload-artifact@043fb46d said v4.5.0 really v7.0.1
actions/download-artifact@3e5f45 said v4.1.4 really v8.0.1
pypa/gh-action-pypi-publish@dc37 said release/v1 really v1.14.2
The last is not a lie - naming the branch is a legitimate convention, and
dtolnay/rust-toolchain@... # stable is left exactly as it is for that reason. But
it leaves Dependabot no version to compare against, which is why it keeps
proposing 1.14.2 over a pin that already IS 1.14.2 (#30).
All five share one signature: a bump replaced the SHA and left the comment behind.
Nothing in CI could see it, because a stale comment is still valid YAML and the
workflow runs perfectly - just not the version everyone believes it runs.
WHY THIS IS NOT COSMETIC
The comment is the only human-readable part of a SHA pin. Wrong, it breaks three
things at once:
- Reviewers approve a version they were never shown. The diffs above understate
what runs by three and four major versions.
- Dependabot proposes bumps that are already applied, because it trusts the
comment. #27, #28, #30 and #31 are all CONFLICTING or failing for this reason
and this reason alone.
- "Pin to SHA" stops buying anything if nobody can tell which release the SHA
is, and the label they use to tell is wrong.
THE GATE
Fixing five comments without adding a check just resets the clock, so:
scripts/check_action_pin_comments.py resolves every pinned SHA against the
upstream tag list and fails on disagreement. It reads only public tags, so
GITHUB_TOKEN suffices and it runs on Dependabot and fork PRs - the PRs where
this symptom actually surfaces. Comments naming a branch are reported, not
failed.
tests/unit/test_action_pin_comments.py checks offline what can be checked
offline: no bare SHAs, one SHA never labelled two versions, one version label
never pointing at two SHAs, nothing pinned to a mutable ref.
Both were verified to BITE, not just to pass: reintroducing the v4.2.2 comment
makes the script exit 1 with the mismatch named, and fails the offline test that
one SHA carries two labels. Clean, the script reports 13 pins agreeing and 0
disagreeing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
publish.ymlpinned SHAs for v7.0.1 and v8.0.1 while the comments read# v4.5.0and# v4.1.4. Confirmed against the upstream tag lists.My fault. Rebuilding the Dependabot branches on the RC replaced each SHA and left the trailing comment untouched, so every reader has since been told the workflow runs v4.5.0 while it actually runs v7.0.1 — a three-major gap in what a reviewer thinks they are approving.
The comment is the only human-readable part of a SHA pin. A wrong one is worse than none: it looks like provenance and is misinformation.
It also explains the conflicts
Dependabot #27 and #28 are
CONFLICTINGbecause Dependabot reads the comment, believes the pin is v4.5.0, and proposes bumping to the SHA already present. With the comments corrected they are redundant rather than conflicting — they propose exactly what is pinned.🤖 Generated with Claude Code