Finding
The shared hybrid gate always provisions a Rust toolchain and cargo-nextest in
its full-build path, even when a caller has no Cargo workspace and supplies only
non-Rust commands. The caller can choose a toolchain string but cannot select a
command-only runner profile or disable Rust setup.
Evidence
At immutable .github commit
d49f2e27f8ce11005529f28effedbfd430891711:
.github/workflows/hybrid-gate.yml:55-66 defines rust_toolchain but no
runner-profile or setup-Rust input..github/workflows/hybrid-gate.yml:305-315 runs
actions-rust-lang/setup-rust-toolchain unconditionally..github/workflows/hybrid-gate.yml:317-335 detects Cargo.toml only after
Rust setup and uses the result solely to gate the cache..github/workflows/hybrid-gate.yml:374-377 installs cargo-nextest
unconditionally.- Dioptron
main@8b3fbe8b7c34355498a26f6870b6ac5235a29738
has no Cargo workspace. Its
.github/workflows/gate-attestation.yml:30-44 supplies a synthetic stable
toolchain value only because the reusable provisions Rust, while all four
mandatory commands are real Python or document checks.
No open issue in this repository covers the unconditional runner substrate.
Issues #17, #19, #61, and #63 address different contracts.
Why this matters
A reusable gate should provision only the mechanism required by the selected
verification contract. Unconditional Rust and nextest installation adds
latency, network and supply-chain surface, and avoidable failure modes to
docs-only and other non-Cargo repositories. It also makes the caller declare a
Rust toolchain that is not part of its product, creating configuration whose
only consumer is unwanted setup.
Desired correction
Add a closed runner profile, such as rust and command-only, or an equivalent
validated setup_rust contract. Keep the current Rust behavior as the default
for existing consumers. In command-only mode, skip Rust toolchain setup, Cargo
manifest/cache handling, cargo-nextest installation, and Rust-specific failure
artifacts while still running every caller command and the terminal gate.
Do not infer the profile from command text and do not let command-only mode turn
mandatory command slots into no-ops.
Done when:
- unknown runner profiles fail before verification begins;
- existing callers retain the Rust profile without behavior drift;
- fixtures prove command-only mode performs no Rust or nextest setup but runs
every supplied non-vacuous command and reports the terminal gate; - fixtures prove a command failure remains a failed terminal gate; and
- Dioptron or another no-Cargo consumer exercises the command-only profile on a
real pull-request head.
Finding
The shared hybrid gate always provisions a Rust toolchain and cargo-nextest in
its full-build path, even when a caller has no Cargo workspace and supplies only
non-Rust commands. The caller can choose a toolchain string but cannot select a
command-only runner profile or disable Rust setup.
Evidence
At immutable
.githubcommitd49f2e27f8ce11005529f28effedbfd430891711:.github/workflows/hybrid-gate.yml:55-66definesrust_toolchainbut norunner-profile or setup-Rust input.
.github/workflows/hybrid-gate.yml:305-315runsactions-rust-lang/setup-rust-toolchainunconditionally..github/workflows/hybrid-gate.yml:317-335detectsCargo.tomlonly afterRust setup and uses the result solely to gate the cache.
.github/workflows/hybrid-gate.yml:374-377installs cargo-nextestunconditionally.
main@8b3fbe8b7c34355498a26f6870b6ac5235a29738has no Cargo workspace. Its
.github/workflows/gate-attestation.yml:30-44supplies a syntheticstabletoolchain value only because the reusable provisions Rust, while all four
mandatory commands are real Python or document checks.
No open issue in this repository covers the unconditional runner substrate.
Issues #17, #19, #61, and #63 address different contracts.
Why this matters
A reusable gate should provision only the mechanism required by the selected
verification contract. Unconditional Rust and nextest installation adds
latency, network and supply-chain surface, and avoidable failure modes to
docs-only and other non-Cargo repositories. It also makes the caller declare a
Rust toolchain that is not part of its product, creating configuration whose
only consumer is unwanted setup.
Desired correction
Add a closed runner profile, such as
rustandcommand-only, or an equivalentvalidated
setup_rustcontract. Keep the current Rust behavior as the defaultfor existing consumers. In command-only mode, skip Rust toolchain setup, Cargo
manifest/cache handling, cargo-nextest installation, and Rust-specific failure
artifacts while still running every caller command and the terminal gate.
Do not infer the profile from command text and do not let command-only mode turn
mandatory command slots into no-ops.
Done when:
every supplied non-vacuous command and reports the terminal gate;
real pull-request head.