ci: zizmor fails every PR when an upstream action moves its major tag #1712

Impact

Since about 10:08 UTC on 2026-10-07, the actions-audit / zizmor check fails on every PR, whatever the PR changes. #1709 only touches mellea/backends/openai.py and its test and still goes red. The check isn't required, so merges still go through, but contributors can't fix it from their own branch, and a security audit that's red on every PR soon stops being read.

Cause

actions/upload-artifact v7.0.2 and actions/download-artifact v8.0.2 were released on 2026-10-07, and both projects moved their floating v7/v8 tags onto the new commits. docs-publish.yml pins the previous patch releases by SHA but labels them with the major tag only:

# docs-publish.yml:155 and :163 (SHA is v7.0.1)
uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
# docs-publish.yml:210 (SHA is v8.0.1)
uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8

zizmor's online ref-version-mismatch audit resolves the tag named in the comment and compares it with the pinned SHA. Once v7 moved they disagree: 3 medium findings, exit code 13. zizmor was v1.29.0 in both the last green run (merge queue for #1706) and the red ones, so the tag move is the trigger. It reproduces locally with GH_TOKEN=$(gh auth token) uvx zizmor@1.29.0 --config .github/zizmor.yml .

The same failure is queued up elsewhere

11 more pins carry a major-only comment. They pass today only because upstream hasn't released since:

• astral-sh/setup-uv@37802adc… # v7, 9 lines (SHA is v7.6.0)
• actions/setup-node@49933ea… # v4, 2 lines (SHA is v4.4.0)

Proposed fix

1. Rewrite all 14 comments to the exact release the SHA points at (# v7.0.1, # v8.0.1, # v7.6.0, # v4.4.0). Patch tags don't move, so the comment can't drift. No action versions change.
2. Add a pygrep pre-commit hook that rejects @<sha> # vN and @<sha> # vN.M comments. CI already runs pre-commit run --all-files, so the pattern can't creep back in.
3. Add a row to the AGENTS.md §9 Common Issues table.

Online audits stay on. They also run the impostor-commit and known-vulnerable-action checks, which is most of the value of auditing PRs.

Open question: keeping pins current

We don't use Dependabot or Renovate, so a pin only moves when someone edits it by hand. A github-actions Dependabot config (weekly, grouped into one PR) would update each SHA and its comment together, at the cost of one bot PR a week through normal PR CI. That's a project decision, so it's raised for discussion here and not part of the fix. If we adopt it, zizmor's dependabot-cooldown audit requires a cooldown, a ci commit prefix keeps pr-label happy, and the DCO app already skips bot-authored commits.

Notes

• zizmor's own version is already fixed. zizmor-action maps latest to an image digest baked into each action release, so zizmor only changes when the zizmor-action pin is bumped, and any new findings surface on that bump.
• zizmor 1.30.1 reports 7 more findings on main than 1.29.0: 5 from the new self-repository audit, and 2 ref-version-mismatch on the # main comments in hold.yml and pr-label.yml. Those get handled when the first zizmor-action bump arrives; they're out of scope here.
• Open PRs need a fresh push or a rebase onto main to pick up the fix. A plain re-run reuses the original merge commit and fails again.