Fix stale version comments on five SHA-pinned actions by helgafinn · Pull Request #2015 · sigstore/policy-controller · GitHub
Skip to content

Fix stale version comments on five SHA-pinned actions - #2015

Open
helgafinn wants to merge 1 commit into
sigstore:mainfrom
helgafinn:fix/stale-action-version-comments
Open

helgafinn wants to merge 1 commit into
sigstore:mainfrom
helgafinn:fix/stale-action-version-comments

Conversation

@helgafinn

Copy link
Copy Markdown

Summary

Five SHA-pinned action references carry a version comment naming a release the pinned commit does not have. Every SHA is left untouched — only the comments change, so there is no behavioural difference and CI behaviour is identical.

File Action Pinned SHA Comment says Commit actually is
codeql-analysis.yml:64 github/codeql-action ff2f1c62 v3.29.5 v4.37.7
codeql-analysis.yml:73 github/codeql-action ff2f1c62 v3.29.5 v4.37.7
scorecard_action.yml:56 github/codeql-action ff2f1c62 v3.29.5 v4.37.7
kind-cluster-image-policy-tsa.yaml:120 sigstore/cosign-installer d58896d6 v2 v3.9.2
kind-cluster-image-policy-tsa.yaml:148 actions/checkout 3d3c42e5 v3.0.2 v7.0.1

Each is behind by at least one major version, which is the direction that misleads: someone auditing kind-cluster-image-policy-tsa.yaml sees checkout # v3.0.2 and reasonably concludes the workflow is four majors behind, when the pin is actually current.

The checkout one is self-evident from this repo alone. The same commit 3d3c42e5 is pinned in four places and correctly labelled # v7.0.1 in three of them — codeql-analysis.yml:44, scorecard_action.yml:27, and kind-cluster-image-policy-tsa.yaml:95. Only line 148 of that last file says v3.0.2. One of the two labels has to be wrong, and the tag data says it is line 148.

The cosign-installer one is worth a second look for a different reason — the comment says v2 while the pinned commit is v3.9.2, and v3 was the release that changed which cosign version gets installed. The pin is right; only the label suggests otherwise.

Why this drifts

Nothing validates a version comment. GitHub enforces the SHA and ignores the comment entirely, so when a SHA is bumped and the comment is not, the file keeps building fine and the discrepancy is invisible until someone reads it.

Verification

Two calls per row — the tag the pinned commit carries, and where the claimed tag actually points:

# what does the pinned commit actually carry?
gh api repos/actions/checkout/tags --paginate \
  --jq '.[] | select(.commit.sha=="3d3c42e5aac5ba805825da76410c181273ba90b1") | .name'
# -> v7.0.1, v7

# and where does the claimed tag point?
gh api repos/actions/checkout/git/ref/tags/v3.0.2 --jq '.object.sha'
# -> 2541b1294d2704b0964813337f33b291d3f8596b   (a different commit)

Same shape for the other two actions. Every pinned action across .github/workflows/ was checked — 103 pins — and these five were the only mismatches.

Scope

Comment-only, so nothing to test beyond CI staying green.

Deliberately not included, since they are decisions rather than factual errors:

  • Several of these pins are genuinely old. Bumping them is a real change that deserves its own PR and its own test run.
  • Comment style varies across the workflows here (# vX.Y.Z vs bare). I kept each line's existing form so the diff is only the version token.

codeql-action ff2f1c62 is labelled v3.29.5 but is v4.37.7, cosign-installer
d58896d6 is labelled v2 but is v3.9.2, and checkout 3d3c42e5 is labelled
v3.0.2 but is v7.0.1. In each case the claimed tag resolves to a different
commit.

Comments only, no SHA changes, so workflow behaviour is unaffected.

Signed-off-by: Helga <noahuhryan@gmail.com>
@helgafinn
helgafinn requested a review from a team as a code owner September 8, 2026 04:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant