ci: pin every bare actions/*@vN reference to a full commit SHA (BE-5121) - #92
ci: pin every bare actions/*@vN reference to a full commit SHA (BE-5121)#92mattmillerai wants to merge 1 commit into
Conversation
Seven workflow files still referenced first-party actions by mutable major
tag, contrary to the repo rule in AGENTS.md ("Pin everything by full commit
SHA, with a trailing '# vN' comment"). A moved tag silently changes what runs
in CI here and, via the reusable workflows, for every consumer.
Every SHA reuses the pin already present elsewhere in this repo for the same
major version, and each was independently confirmed against the live tag with
'gh api repos/actions/<name>/commits/<tag>'. Same major versions as before, so
no behaviour change is expected.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 58 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
Comment |
mattmillerai
added
agent-coded
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🔍 Cursor Review — Consolidated panel
Triggered by @mattmillerai.
✅ No high-signal findings.
Panel: 8/8 reviewers contributed findings.
2 participants
ELI-5
GitHub Actions lets you say "run version 6 of the checkout action". But
v6is just a sticky note that whoever owns the action can move to point at different code whenever they like. If someone hostile (or just careless) moves it, our CI silently starts running something else — and because this repo publishes reusable workflows, that change would ride along into every consumer repo that calls them. This PR replaces each sticky note with the exact commit it currently points at, and leaves a# v6comment so a human can still read which version it is.What changed
Twenty
uses:lines across seven workflow files went from a bare major tag to a full 40-character commit SHA with a trailing version comment. No other change — no logic, no inputs, no permissions.actions/checkout@v6@d23441a48e516b6c34aea4fa41551a30e30af803 # v6actions/setup-python@v6@ece7cb06caefa5fff74198d8649806c4678c61a1 # v6actions/upload-artifact@v7@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7actions/download-artifact@v8@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8actions/create-github-app-token@v3@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0actions/github-script@v9@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0Files:
cursor-review.yml,cursor-review-auto-label.yml,agents-md-integrity.yml,assign-prs-to-author.yml,test-cursor-review-scripts.yml,test-agents-md-integrity.yml,test-bump-callers.yml.Why
AGENTS.md: "Pin everything by full commit SHA, with a trailing# v1comment — both theuses:in callers and every third-party action here." These seven files were the remaining exceptions. The motivation is the repo's own stated standard plus mutable-tag supply-chain risk — not a failing check: thepinact/zizmorvalidation consumer repos run inspects the consumer's own caller files, not this reusable workflow's internal action refs, so nothing is red today.Raised on #91 (#91 (comment)) and deferred there, because pinning only the four lines that PR added would have left
cursor-review.ymlinternally inconsistent while fixing nothing.How the SHAs were chosen
Every SHA is one this repo already uses elsewhere for the same major version, so the pins are internally consistent rather than newly invented. Each was then independently confirmed against the live tag with
gh api repos/actions/<name>/commits/<tag>— both sources agreed on all six. Since each pin resolves to the tip the mutable tag points at today, the same code runs before and after: no behaviour change is expected.Verification
grep -rn 'uses: actions/[a-z-]*@v[0-9]*$' .github/workflows/→ no matches (the ticket's acceptance check).uses:line in.github/workflows/now carries a 40-hex SHA, with one deliberate exception:ci-groom.yml:95, whose@REPLACE_AT_MERGE_WITH_THIS_PRS_SQUASH_SHAplaceholder is the documented bump-at-merge marker, not a mutable tag.shellcheckclean + 123 assertions).check_agents_md.py --root .passes (its one warning — no CODEOWNERS — pre-exists this change).Judgment calls
checkout/setup-python/upload-artifact/download-artifactget# v6/# v7/# v8andcreate-github-app-token/github-scriptget# v3.2.0/# v9.0.0, because that is exactly what the existing pinned lines in this repo already say for those SHAs. Uniformity across actions would have meant rewriting lines outside this PR's scope.ci-groom.ymlleft alone — see above; it is the intentional placeholder, and it is not anactions/*ref.main. It describescursor-review.ymlas carrying 13checkout@v6, 2upload-artifact@v7, 3download-artifact@v8and 1create-github-app-token@v3; the file onmaintoday has 7, 1, 1 and 2 respectively (the counts were taken during the feat(cursor-review): prior-review ledger so re-reviews stop re-litigating answered findings (BE-5109) #91 review and the file has moved since). The acceptance criterion is the grep, which is satisfied — but flagging the discrepancy rather than quietly reconciling it.Risk
The riskiest thing here is a single mistyped SHA, which would fail every affected job loudly and immediately rather than degrade silently. That risk is covered by the two-source check above. Consumers are unaffected either way — they pin this repo by SHA, so nothing changes for them until they bump.