setup: consume tool versions from a canonical manifest

[ppenna]

Follow-up to #128.

Summary

Move setup-tool versions and integrity metadata into one canonical, machine-readable source and have every platform setup script consume that source instead of maintaining independent literals.

The currently duplicated pins include:

• Rust toolchain and minimum Rust version;
• rustup version and platform-specific SHA-256 hashes;
• cargo-nextest version;
• sccache version and platform-specific SHA-256 hashes; and
• GitHub Actions runner version and platform-specific SHA-256 hashes.

These values currently appear across scripts/setup/setup-linux-runner.sh, scripts/setup/setup-linux-mshv.sh, scripts/setup/setup-windows-whp.ps1, setup documentation, and tests.

Motivation

The Linux and Windows setup paths are expected to install matching tool versions, but each script declares its own constants. Updating a tool therefore requires coordinated edits across several files, and it is possible for platforms, documentation, or tests to drift silently.

The Linux setup consolidation tracked by #128 is a good opportunity to separate tool-version policy from platform-specific installation logic.

Requirements

• Add one checked-in canonical source for setup-tool versions.
• Represent platform-specific artifact names and SHA-256 hashes where binaries differ between Linux and Windows.
• Have the unified Linux setup path and setup-windows-whp.ps1 consume the canonical values.
• Preserve checksum verification before executing or installing downloaded binaries.
• Keep fresh-host bootstrap self-contained: reading the canonical source must not require an undeclared tool or package that has not yet been installed.
• Fail explicitly when the manifest is missing, malformed, incomplete, or contains an unsupported platform/architecture.
• Keep the source usable from both POSIX shell and PowerShell without duplicating version policy in language-specific constants.
• Update documentation to reference or derive from the canonical source instead of repeating version literals where practical.
• Replace tests that assert hard-coded versions in individual scripts with tests that verify all consumers use the canonical source and that required version/hash entries exist.
• Ensure .github/actions/validate-nvx/action.yml exercises the relevant consistency tests on Linux and Windows.

Suggested schema coverage

At minimum, the canonical data should cover the current values for:

• rust.toolchain
• rust.minimum_version
• rustup.version
• rustup.artifacts.<platform-architecture>.sha256
• cargo_nextest.version
• sccache.version
• sccache.artifacts.<platform-architecture>.sha256
• actions_runner.version
• actions_runner.artifacts.<platform-architecture>.sha256

The exact file format and location can be selected during implementation, provided it remains straightforward to review and consume during bootstrap.

Acceptance criteria

• A tool-version upgrade requires changing the version in exactly one canonical source.
• Linux and Windows setup scripts resolve the same shared versions from that source.
• Platform-specific checksums remain explicit and independently verified.
• Setup fails before installation when canonical metadata is invalid or incomplete.
• CI detects consumers that reintroduce divergent hard-coded pins.
• Setup documentation and tests no longer need coordinated literal-version edits for routine tool upgrades.

[pranavjindal29]

Hi, I’d like to work on this issue.

I’m planning to first check where the tool versions and checksums are currently duplicated, then move them into a single manifest and update the setup scripts to read from it. I’ll keep the changes focused and follow the existing setup patterns in the repo.