Pin `actions/upload-artifact` and `actions/download-artifact` in `.github/workflows/release.yaml` to full commit SHAs

[fullsend-ai-retro]

What happened

The review agent flagged actions/upload-artifact@v7 (line ~117) and actions/download-artifact@v8 (line ~155) in .github/workflows/release.yaml as tag-only references on PR #1684 across 6 review runs between 2026-06-18 and 2026-09-04. Every other third-party action in the repo — including actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 in .github/workflows/scorecards.yml:84 — is SHA-pinned. The release.yaml create_release job runs with contents: write, so a repointed tag on either action could publish arbitrary content as part of a release. The PR merged 2026-09-15 without addressing the note, and the same finding will resurface on the next Renovate bump of these two actions.

What could go better

Filing this in the source repo — rather than letting the review agent re-flag it indefinitely — gives the maintainers a place to either fix it or explicitly close it as won't-fix (with a rationale the review agent can be pointed at). The current state (.github/workflows/release.yaml tag-pinned while scorecards.yml SHA-pinned for the same action) is a real inconsistency in supply-chain posture even if the practical risk is low for GitHub-maintained actions. Confidence: high on the observation; medium on whether the repo owners consider it worth fixing (their merge behavior on #1684 is consistent with won't-fix).

Proposed change

Edit .github/workflows/release.yaml: change uses: actions/upload-artifact@v7 (line ~117) to uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 (matching scorecards.yml). Change uses: actions/download-artifact@v8 (line ~155) to uses: actions/download-artifact@<v8.0.1 sha> # v8.0.1. Ensure renovate.json (or the shared conforma/.github config it extends) uses pinDigests: true for GitHub Actions so future bumps preserve the SHA form. If the maintainers prefer tag-only for these two references, close this issue as won't-fix with a comment stating the rationale so future review runs can be pointed at it.

Validation criteria

After the change: (a) grep -rE 'uses: actions/(upload|download)-artifact@v[0-9]+$' .github/workflows/ returns no matches; (b) the next Renovate major/minor bump for either action produces a diff that keeps the SHA form (via pinDigests); (c) the next re-review of a Renovate action-bump PR against conforma/policy no longer emits the tag-only pinning finding for release.yaml.

---

Generated by retro agent from #1684

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 1:50 PM UTC · Completed 1:54 PM UTC

Commit: cd01138 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-7 · Effort: high · Cost: $0.87

[fullsend-ai-triage]

Thanks for filing, but this appears to be a false positive from the upstream review run.

On release-v0.7 (the branch PR #1684 targeted), both actions at the cited lines are already SHA-pinned:

• Line 117: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
• Line 155: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8

Both values are 40-character commit SHAs with a version comment — the same SHA-pinning form the retro compares against in scorecards.yml. On main, release.yaml doesn't reference either action at all. A repo-wide grep across .github/workflows/ confirms every third-party action is already SHA-pinned.

Closing as not planned since there's no change to make. If the review agent re-flags this on a future Renovate bump, please point it at this issue as the standing rationale — Renovate's pinDigests config already keeps the SHA form on bumps, so the pattern is expected to persist.

---

Labels: The issue was auto-filed as a supply-chain hygiene retro against the GitHub Actions workflow files; github_actions reflects the affected area and wontfix matches the not-planned close reason.