fix(ci): pin cargo-geiger where the action actually reads the version

[chaliy]

What changed

Nightly's cargo-geiger is pinned for real this time, as
tool: cargo-geiger@0.13.0. Adds a test that fails on both halves of the
mistake that made the first attempt a no-op.

Follow-up to #2715, whose geiger half did not work. The dd and wasmtime halves
of that PR did land correctly; this fixes only the third.

Why

#2715 pinned the tool with a version: input. That action has no such input,
and GitHub Actions treats an unknown input as a warning, not an error — so
the pin was dropped on the floor and the step kept installing the newest
release. I dispatched nightly on the merged commit to check, and run 260 failed
exactly as run 259 had:

+ cargo install -f cargo-geiger --root /opt/hostedtoolcache/cargo-geiger --locked --version 0.14.0
error: cannot install package `cargo-geiger 0.14.0`, it requires rustc 1.97 or
newer, while the currently active rustc version is 1.95.0

##[warning]Unexpected input(s) 'version', valid inputs are
['tool', 'locked', 'git', 'tag', 'rev', 'features', 'no-default-features', 'all-features']

What made the wrong spelling look right: the original failure log prints
INPUT_VERSION: 0.14.0, which is the action's own resolved value, not an
input it accepts. The version belongs in tool: as name@version.

Before / After

Before — version: ignored, --version 0.14.0 on the command line, job
red in 1s, the unsafe-code audit and its report upload both skipped.

After — the version reaches the action, which installs 0.13.0 (MSRV 1.85)
under the pinned 1.95.0. That install is the one already shown working on this
toolchain in #2715:

$ cargo install cargo-geiger --locked --version 0.13.0 --root <tmp>
   Installed package `cargo-geiger v0.13.0` (executable `cargo-geiger`)
[exited with code 0]

The new test, scripts/tests/test_pinned_ci_tools.py, reintroducing the
exact spelling I shipped — it catches both halves:

FAIL: test_no_step_passes_an_input_the_action_ignores (... input='version')
AssertionError: nightly.yml:security-analysis passes 'version' to
taiki-e/cache-cargo-install-action, which does not accept it; the runner only
warns, so it is silently ignored

FAIL: test_tools_on_the_pinned_toolchain_pin_a_version (... tool='cargo-geiger')
AssertionError: nightly.yml:security-analysis builds 'cargo-geiger' from source
on the pinned toolchain with no version; pin it as `tool: name@version` ...

Ran 3 tests — FAILED (failures=2)

and passes on the corrected one:

$ python3 -m unittest discover -s scripts/tests -p 'test_*.py'
Ran 162 tests in 6.786s

OK

Nightly only runs on a schedule, so I will dispatch it on main after this
merges rather than claim it green from the config alone — which is the mistake
#2715 made.

Risk

• Low
• One workflow line and one new test file. No production code, and nothing on
  the required-CI path changes behavior.
• The pin requirement is scoped to jobs on the pinned toolchain. A job
  installing the nightly toolchain is exempt, because nightly outruns any
  released MSRV — that is why cargo-fuzz in the fuzz job needs no pin, and
  the test would be wrong to demand one. It detects the channel from the
  # nightly comment on the dtolnay/rust-toolchain ref, which dependabot
  moves together with the SHA.
• The allowed-input list is copied from the action's own error message, so a
  future version of the action that adds an input will fail this test until
  the list is updated. That is the intended direction: better a loud failure
  than another silently-ignored input.
• 0.13.0 is an older geiger than 0.14.0, so any detection improvement there is
  deferred until the toolchain reaches 1.97.

Checklist

• Tests added or updated — scripts/tests/test_pinned_ci_tools.py, in the
  suite required CI already discovers, shown failing on the exact broken
  spelling and passing after. Also just check-workflow-parity ("release
  workflows match CI for: node, python; rust toolchain pins agree").
• Backward compatibility considered — CI-only; no public surface.

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	17a17d8	Commit Preview URL Branch Preview URL	Oct 13 2026, 10:38 AM

[chaliy]

Since the last attempt was wrong on exactly this point, here is the spelling checked against the action's own source at the SHA we pin, rather than against convention.

action.yml declares eight inputs — tool, locked, git, tag, rev, features, no-default-features, all-features. There is no version, which is what the runner warning said.

pre.sh is where the version actually comes from:

tool="${INPUT_TOOL:?}"
...
if [[ "${tool}" == *"@"* ]]; then
  version="${tool#*@}"
  tool="${tool%@*}"
  if [[ ! "${version}" =~ ^(...semver...)$|^latest$ ]]; then
    bail "cache-cargo-install-action does not support non-semver version: '${version}'"
  fi
...
else
  version=latest
fi

Three things that settle it:

1. <tool>@<version> is the supported syntax — the script splits on @, and names it in its own error text ("<tool>@<version> syntax is not supported with 'git' input option").
2. The else branch sets version=latest. That is precisely why the unpinned step resolved to 0.14.0, and why INPUT_VERSION: 0.14.0 showed up in the log as the action's computed value rather than as something we passed.
3. 0.13.0 matches the semver pattern, so it will not bail.

The pre step then exports version to the install step as INPUT_VERSION, which becomes cargo install --version.

I'll still dispatch nightly on main after this merges and report the result, rather than calling it green from the config.

---

Generated by Claude Code