chore: add CI gate before release + pin action versions to commit SHAs

[jflowers]

Summary

Two related supply-chain hygiene issues:

1. No CI gate before release

release.yml triggers on any v* tag push and runs GoReleaser immediately with no CI preflight verification. A tag pushed from a commit that never passed tests will produce and distribute release binaries.

2. Floating action tags

CI workflows use mutable floating action tags (actions/checkout@v4, actions/setup-go@v5) instead of commit SHA pins. All other repos in the org pin actions to full commit SHAs. The project's own severity.md classifies unpinned CI actions on mutable tags as HIGH severity supply-chain risk.

Expected behavior

1. Release preflight: Before GoReleaser runs, verify that Build and Test CI checks passed on the tagged commit (matching the pattern in unbound-force/unbound-force/.github/workflows/release.yml lines 78-110)
2. Pin actions: Replace floating tags with full commit SHAs (e.g., actions/checkout@v4 -> actions/checkout@<commit-sha>)

Location

• .github/workflows/release.yml
• .github/workflows/ci.yml

[jflowers]

Partial mitigation applied: A tag ruleset (release-tag-protection, ID: 17231976) has been created on this repo that restricts v* tag creation, deletion, and force-pushing to org admins only.

This addresses the who can trigger a release surface but does not address either of the two items in this issue:

1. CI preflight gate: An org admin can still push a v* tag on a commit that never passed tests. A workflow preflight step is still needed.
2. Pinned action SHAs: CI workflows still use floating action tags (@v4, @v5) instead of commit SHA pins. This is unrelated to tag rulesets and still needs a workflow file change.

Remaining work: Add a preflight step to release.yml and pin all action references to commit SHAs in both release.yml and ci.yml.

[jsvob]

Output from unbound-force:

Comment for replicator#15

Paste this as a comment on #15

---

Hi Jay — triaging this so it's ready to implement. Here's everything you need to pick it up without rework.

What needs to change

Two files, no Go code:

• .github/workflows/ci.yml — pin action SHAs, add permissions:, add concurrency:
• .github/workflows/release.yml — switch trigger to workflow_dispatch, add preflight job, pin action SHAs, update sign-macos tag references

Current state

ci.yml (26 lines, very simple):

jobs:
  test:                              # job named "test"
    steps:
      - uses: actions/checkout@v4   # unpinned
      - uses: actions/setup-go@v5   # unpinned

No permissions: block, no concurrency: group.

release.yml (195 lines):

on:
  push:
    tags: ['v*']                     # fires immediately, no CI check
permissions:
  contents: write                    # too broad, applies to all jobs
jobs:
  release:
    steps:
      - uses: actions/checkout@v4            # unpinned
      - uses: actions/setup-go@v5            # unpinned
      - uses: goreleaser/goreleaser-action@v6 # unpinned

The sign-macos job uses $GITHUB_REF_NAME throughout (download artifact, upload asset, tag the cask commit). After switching to workflow_dispatch, GITHUB_REF_NAME will be the branch name, not the tag — so every reference needs to become ${{ inputs.tag }} (or a job-level env: RELEASE_TAG: ${{ inputs.tag }}).

Canonical reference

unbound-force/unbound-force/.github/workflows/release.yml — the full preflight pattern to replicate. Key elements:

• workflow_dispatch with tag input
• preflight job: tag format validation → tag uniqueness → semver ordering → CI status check via GitHub Checks API → unreleased-commits check → tag creation → signing-secrets detection
• release job gets needs: preflight
• permissions: {} at workflow level, per-job permissions only
• concurrency: group at workflow level
• All actions pinned to full commit SHAs

Action SHAs to use

Action	Floating tag	SHA to pin	Version
actions/checkout	@v4	11bd71901bbe5b1630ceea73d27597364c9af683	v4.2.2
actions/setup-go	@v5	f111f3307d8850f501ac008e886eec1fd1932a34	v5.3.0
goreleaser/goreleaser-action	@v6	9c156ee8a17a598857849441385a2041ef570552	v6.3.0

(SHA values confirmed from the dewey repo's pinned ci.yml for checkout/setup-go; goreleaser SHA from the v6.3.0 release commit.)

One decision needed before implementation

The CI check name used in the preflight.

The preflight job calls the GitHub Checks API to verify CI passed on HEAD before allowing the release to proceed. It does this by check name string. The canonical reference looks for "Build and Test" — but replicator's current ci.yml names its job test, which means the check appears in GitHub as "test".

Two options:

Option A — Rename the ci.yml job to "Build and Test" (aligns with org convention, matches check name the preflight will look for, consistent with dewey which also uses build-and-test). Small visible change: the CI status badge/check name changes on existing PRs momentarily.

Option B — Keep the job name test and look for "test" in the preflight. Simpler, no CI check name churn, but diverges from org convention and makes the preflight harder to read.

Recommendation: Option A. The job rename is a one-liner and produces a more readable preflight. But this is your call since it's a visible CI change.

What to do with the security scan check

The canonical preflight also checks that at least one of "OSV-Scanner / ..." checks passed. Replicator's CI has no security scan step. The simplest correct approach: omit the security scan block from the preflight entirely. If you want to add a govulncheck step to CI at the same time, that's a natural companion change — but it's out of scope for this issue.

No cross-PR conflicts

This PR touches only .github/workflows/ files in the replicator repo. No other open PRs touch these files here. The parallel dewey#65 PR is in a different repo entirely.jsvoboda@jsvoboda-thinkpadx1carbongen12: