ci: pin cargo-audit on the blocking gate, float the weekly canary

[beardthelion]

The PR-blocking audit job installs cargo-audit with an unpinned cargo install --locked cargo-audit, so the scanner floats to the latest release on every run. A regressed release then reds the gate repo-wide with no code change, the same spontaneous-breakage class the quinn-proto advisory exposed but on the scanner itself. #57 added the unpinned install; nothing has pinned it since.

pr-checks.yml (the gate): pinned to --version 0.22.2 (what the unpinned install currently resolves to). cargo install --version X is an exact pin, not a caret, so it freezes the binary; the RustSec advisory DB is still fetched fresh at scan time, so this does not weaken what the gate catches. The step also asserts the resolved version after install, so an accidental future unpin fails loud instead of silently running a different scanner, and the cargo-audit version is now part of the rust-cache key so hits stay deterministic.

audit-schedule.yml (weekly canary): left deliberately unpinned. It is cron-only and never gates a merge, so floating it cannot block a PR; if a newer cargo-audit regresses, the weekly run reds or its report changes, which is the drift signal that latest has moved and the gate's pin should not be bumped yet.

If 0.22.2 is ever yanked the gate's install fails loud until bumped; that bump path is documented in the step comment.

Summary by CodeRabbit

• Chores
  • Updated CI audit checks to use a pinned cargo-audit version for PR validation, with an added runtime version check to prevent unexpected tool changes.
  • Adjusted the scheduled audit job to use a floating scanner as a drift canary, with clearer workflow documentation.

[coderabbitai]

📝 Walkthrough

Walkthrough

Two GitHub Actions workflow files are updated: the PR-checks audit job now pins cargo-audit to version 0.22.2 with a matching cache key and runtime version verification, while the scheduled audit workflow's cargo-audit install step is renamed and documented as an intentionally unpinned drift canary.

Changes

CI cargo-audit workflow changes

Layer / File(s)	Summary
Pin cargo-audit version in PR-checks audit job .github/workflows/pr-checks.yml	Cache key updated to audit-0.22.2, cargo-audit installed pinned via cargo install --locked --version 0.22.2 cargo-audit, and a runtime check fails the job if the installed version doesn't match.
Document scheduled audit as unpinned drift canary .github/workflows/audit-schedule.yml	Renames the install step and adds comments clarifying the cron-only job intentionally installs an unpinned scanner as a drift canary, without gating merges.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Possibly related PRs

• Gitlawb/node#57: Modifies the same cargo-audit installation logic in pr-checks.yml and audit-schedule.yml.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description explains the change, but it doesn't follow the required template or include sections like Kind of change and How to verify.	Rewrite it to match the template: add Summary, Motivation & context with an issue link, Kind of change, What changed bullets, and How a reviewer can verify.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main CI change: pinning cargo-audit on the PR gate while leaving the weekly canary floating.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/pin-cargo-audit-gate

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/pr-checks.yml (1)

136-159: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Consider centralizing the pinned version.

0.22.2 is hardcoded independently in the cache key (Line 136), the install command (Line 150), and the verification grep (Line 156). Bumping the pin later requires updating all three consistently, and any mismatch (e.g. updating the install but not the grep) would cause a false failure or, worse, a silent false pass if the grep were dropped.

♻️ Suggested refactor using a step-scoped env var

+      - name: Install cargo-audit (pinned)
+        env:
+          CARGO_AUDIT_VERSION: 0.22.2
         # ...
         run: |
           set -euo pipefail
-          cargo install --locked --version 0.22.2 cargo-audit
+          cargo install --locked --version "$CARGO_AUDIT_VERSION" cargo-audit
           installed="$(cargo audit --version)"
           echo "cargo-audit installed: $installed"
-          echo "$installed" | grep -qE '(^| )0\.22\.2($| )' || {
-            echo "::error::cargo-audit is not the pinned 0.22.2 (got: $installed)"
+          echo "$installed" | grep -qE "(^| )${CARGO_AUDIT_VERSION//./\\.}($| )" || {
+            echo "::error::cargo-audit is not the pinned ${CARGO_AUDIT_VERSION} (got: $installed)"
             exit 1
           }

The cache key: on Line 136 would still need the literal version since key: doesn't expand shell env vars from a later step, but reducing it to two synchronized spots (workflow-level env + cache key) is still an improvement.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/pr-checks.yml around lines 136 - 159, The pinned
cargo-audit version is duplicated across the cache key, install command, and
version check, which makes future bumps easy to desynchronize. Centralize the
version used by the Install cargo-audit (pinned) step by introducing a single
step-scoped or workflow-scoped version value and reference it from cargo install
and the verification logic, while keeping the cache key aligned to the same pin.
Use the existing Install cargo-audit (pinned) step and the cargo audit --version
check as the main touchpoints.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.github/workflows/pr-checks.yml:
- Around line 136-159: The pinned cargo-audit version is duplicated across the
cache key, install command, and version check, which makes future bumps easy to
desynchronize. Centralize the version used by the Install cargo-audit (pinned)
step by introducing a single step-scoped or workflow-scoped version value and
reference it from cargo install and the verification logic, while keeping the
cache key aligned to the same pin. Use the existing Install cargo-audit (pinned)
step and the cargo audit --version check as the main touchpoints.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 00f2d29f-bc04-49b7-864f-d7d95aba15c1

📥 Commits

Reviewing files that changed from the base of the PR and between 563c456 and 43e7575.

📒 Files selected for processing (2)

• .github/workflows/audit-schedule.yml
• .github/workflows/pr-checks.yml

[jatmn]

Thanks for the contribution. I do not see any actionable issues from my review.

@kevincodex1 LGTM