mirror of
https://github.com/nearai/ironclaw.git
synced 2026-09-06 19:28:23 +08:00
* perf(build): codify CI's debug=0 policy as the workspace dev/test/release profile A handful of lanes (reborn-tests.yml's 10 jobs via workflow env, reborn-e2e.yml's rust-reborn job, platform-and-compat.yml's hooks-parity-tests/windows-build jobs, coverage.yml's coverage job, one live-canary.yml step) already build dev/test at CARGO_PROFILE_DEV_DEBUG=0/ CARGO_PROFILE_TEST_DEBUG=0 via duplicated env decls; this is a true no-op for them. Every other Rust-building job in the repo (code_style.yml's clippy/test jobs, reborn-playwright.yml, sccache-dist-smoke.yml, release-plz.yml, nightly-deep-ci.yml, and most of ironclaw-stress.yml/ live-canary.yml) has never set this env and builds at cargo's full-debug dev default today, so this task changes their build fingerprint and costs each a one-time Swatinem/rust-cache cold miss on its next run. Chosen deliberately: this pays that cost once, up front, for the whole repo, rather than smearing it across the 13 file-swap commits that follow. ironclaw-stress.yml also separately restated CARGO_PROFILE_RELEASE_DEBUG=0 three times (already cargo's built-in release default, and now explicit here too) — release build output is unaffected either way. Measured on ironclaw_common tests: debug=0 175 MiB vs line-tables-only 257 MiB vs full 272 MiB. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci: add the setup-rust composite action (unused by any workflow yet) One component for what toolchain, linker, and profile env a Rust CI job gets: installs via the pinned dtolnay/rust-toolchain SHA, then exports RUSTUP_TOOLCHAIN from the action's own resolved-toolchain output so a job's cargo invocations can never drift from what this step actually installed — no separate mechanism needed for nightly lanes. Optional mold: true absorbs the install/verify/RUSTFLAGS-export steps currently copy-pasted per job. No workflow calls this yet (following tasks swap each file one at a time), so this cannot change CI behavior. New ws12 structural check on the action file itself; self-tested. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(sccache-dist-smoke): install Rust via the setup-rust composite No behavior change: the composite defaults to the same 'stable' toolchain dtolnay/rust-toolchain already defaulted to; this job now also gets RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml landing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(reborn-playwright): install Rust via the setup-rust composite No behavior change: same default toolchain, now with RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml landing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(release-plz): install Rust via the setup-rust composite No behavior change: same default toolchain, now with RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml landing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(nightly-deep-ci): install Rust via the setup-rust composite No behavior change: same default toolchain, now with RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml landing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(reborn-release-compile): install Rust via the setup-rust composite No behavior change: same default toolchain and the same matrix.target input, now with RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(ironclaw-stress): install Rust via the setup-rust composite No toolchain behavior change: same default toolchain, now with RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml landing. Also deletes the three CARGO_PROFILE_RELEASE_DEBUG=0 env decls, already no-ops restating cargo's own release-profile default and now Cargo.toml's explicit [profile.release] debug = 0 (landed in a prior commit). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(code_style): install Rust via the setup-rust composite No behavior change: same default toolchain and the same clippy/rustfmt component inputs, now with RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml landing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(platform-and-compat): install Rust via the setup-rust composite No toolchain behavior change: same default toolchain and the same wasm32-wasip2 target input, now with RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml landing. Deletes two now-redundant CARGO_PROFILE_DEV_DEBUG/CARGO_PROFILE_TEST_DEBUG=0 pairs, no-ops since Cargo.toml's [profile.dev] debug = 0 landed. Also removes the wasm-wit-compat job's now-empty `env:` key left over once both its lines were deleted (a dangling null mapping is valid YAML but dead config; no functional change). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(reborn-e2e): install Rust and mold via the setup-rust composite No behavior change: rust-reborn keeps mold (now via mold: true — same apt install, same verify commands, same canonical RUSTFLAGS prefix, moved into the composite); webui-v2-smoke keeps the same default toolchain. Both now get RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml. Deletes the now-redundant literal mold RUSTFLAGS string and CARGO_PROFILE_*_DEBUG pair. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(coverage): install the nightly toolchain via the setup-rust composite No behavior change: both jobs pass the same explicit toolchain: nightly-2025-11-01 / components: llvm-tools-preview / targets: wasm32-wasip2 as before, now through the composite, which pins RUSTUP_TOOLCHAIN to that exact spec — the same protection the prior design gave these two lanes via a hand-paired job env var, now automatic for every composite call. Deletes the now-redundant CARGO_PROFILE_*_DEBUG pair in the coverage job. check-reborn-branch-coverage-flags.py and reborn_coverage_lane_stack_headroom.rs both still pass (their pinned strings are untouched). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(reborn-tests): install Rust and mold via the setup-rust composite No behavior change to toolchain resolution (same defaults/nightly pins as before, now with RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml) or to the mold linker's effective RUSTFLAGS (the composite's mold: true prepends the canonical prefix onto each job's existing RUSTFLAGS, so the two nightly jobs' -Zcrate-attr suffix is preserved byte-for-byte). Absorbs 7 duplicated mold-install steps and 2 duplicated 'Verify mold linker' blocks into the composite. Two disclosed minor deltas in qa-recorded-fixtures: mold install now includes clang (already present via the runner image; matches the other 6 sites) and now runs after, not before, Install Rust. Deletes the workflow-level mold RUSTFLAGS/ CARGO_PROFILE_*_DEBUG trio, now no-ops. CARGO_INCREMENTAL lines and RUST_MIN_STACK lines are untouched. check-reborn-branch-coverage-flags.py and reborn_coverage_lane_stack_headroom.rs both still pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(live-canary): install Rust via the setup-rust composite No toolchain behavior change: same default toolchain and the same 7 wasm32-wasip2 target inputs, now with RUSTUP_TOOLCHAIN protection ahead of rust-toolchain.toml landing. Deletes the one now-redundant CARGO_PROFILE_DEV_DEBUG='0' step env, a no-op since Cargo.toml's [profile.dev] debug = 0 landed. CARGO_INCREMENTAL is untouched. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * chore(qa): drop the now-redundant CARGO_PROFILE_DEV_DEBUG setdefault Cargo.toml's [profile.dev] debug = 0 is now the workspace default, so this QA harness's env setdefault restates it for no reason. CARGO_INCREMENTAL is untouched — incremental compilation stays a per-caller decision, not a Cargo.toml profile setting (same reasoning applies to the sibling decl in scripts/reborn_qa_matrix/run_hermetic_qa.py:101, left alone). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * build: pin the local Rust toolchain via rust-toolchain.toml Pins exactly what CI's composite-installed toolchain already resolves today (1.98.0 + clippy/rustfmt), so nothing rebuilds and rust-cache keys hold. Safe now that every CI job installs Rust through .github/actions/setup-rust (landed across the prior 13 commits), which exports RUSTUP_TOOLCHAIN and so cannot be overridden by this file landing. Local clippy/rustfmt now match CI's. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(agents): document the toolchain pin and bump process AGENTS.md is scanned by check-guidance.py; .github/workflows/README.md is not (zero hits under ROOT_GUIDANCE/CRATE_GUIDANCE_BASENAMES), so this is the enforced location for the bump instructions Task 19's ws12 guard assumes contributors can find. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(gate): forbid direct dtolnay/rust-toolchain use; enforce the toolchain-pin sync New contracts: no workflow may call dtolnay/rust-toolchain directly (must go through .github/actions/setup-rust) or write out the canonical mold RUSTFLAGS prefix by hand (must pass mold: true); rust-toolchain.toml's channel and the composite's default toolchain input must name the same version. Both are simple negative/equality checks, not per-site window scans — collapsed from the abandoned per-input design specifically because every job now routes through one component. Sabotage tests included. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): let the composite own RUSTFLAGS so job env cannot shadow mold A job-level `env: RUSTFLAGS:` is re-applied to every step of that job on top of whatever earlier steps wrote to $GITHUB_ENV, so it shadows the setup-rust composite's export for the rest of the job — silently dropping the mold linker flags. That hit the two heaviest lanes: crate-tests (the required PR lane and the measured critical path) and reborn-integration-coverage, both of which declared RUSTFLAGS for their nightly `-Zcrate-attr` features. The pre-composite code manually pasted the mold prefix into exactly those two job envs despite the workflow-level env already carrying it, which is the historical symptom of the same shadowing. The composite now takes an `extra_rustflags` input and composes the whole value (mold flags, then the job's flags, then anything already exported), so no job-level declaration is left to shadow it. Both reborn-tests jobs and both coverage.yml jobs pass their crate attributes through the input instead; zero job-level RUSTFLAGS keys remain in the tree. Install Rust precedes every cargo step in all four jobs, so the export covers them. `validate_no_job_env_rustflags_with_setup_rust` pins the invariant: a job installing Rust through the composite may not declare its own RUSTFLAGS. It found the two coverage.yml jobs that this fix would otherwise have missed. Three sabotage tests plus a live-tree assertion cover it. Note for review: GitHub's documentation does not state the $GITHUB_ENV-vs-job-`env` precedence explicitly. This change is correct either way — with no job-level key there is nothing to shadow under any precedence rule — so the fix does not depend on resolving that question. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): map .github/actions/setup-rust/ into the Reborn PR test planner Detect Reborn test scope failed on this PR's own head commit: the planner's fail-closed arm for .github/actions/** had no rule for the new setup-rust composite, so it raised "unmapped test or CI path" and red the whole Tests (Reborn) roll-up. Every Tests (Reborn) job now installs Rust through this composite, exactly like the existing setup-sccache-dist entry in SHARED_REBORN_ACTION_PREFIXES, so it belongs in the same fail-safe-to-full bucket: no narrow lane can exercise a change to it, and a change here means run the exhaustive plan. Generalized the reason string and its test assertion from "shared sccache action changed" to "shared reborn action changed" since the bucket now covers two actions, not one; this is a text-accuracy fix, not a weakened check (still asserts full mode / all partitions / all lanes). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): let has_code see the toolchain pin and its own guard validate_toolchain_pin_sync() only runs inside fast-checks, gated on has_code || has_guidance. The has_code regex enumerated crates/, tests/, Cargo.toml, and friends but not rust-toolchain.toml or .github/actions/setup-rust/ — so a PR touching only the two files the sync guard exists to police got has_code=false, has_guidance=false, and the guard never ran. Add both paths to the has_code regex, and pin them into CRATE_SCOPE_FILTERS' has_code in_scope probes so a future narrowing of the grep fails validate_crate_scope_filters loudly instead of quietly dropping them again. Regression: added a dedicated test asserting rust-toolchain.toml and .github/actions/setup-rust/action.yml are in has_code.in_scope, and confirmed test_checked_in_scope_filters_pass failed against the old regex before fixing .github/workflows/code_style.yml. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): pin the mold verify step's Linux guard in the setup-rust contract validate_setup_rust_action() checked the Linux `if:` guard on the mold install and export steps, but the "Verify mold linker is active" step in between had no constant and no check at all — an unguarded verify step would run the mold link check on any runner OS (where mold and clang are never installed) and nothing would catch it. Add MOLD_VERIFY_STEP to the guarded set validate_setup_rust_action checks. Regression: added test_missing_mold_verify_linux_guard_fails and test_missing_mold_verify_step_fails, confirmed both failed with the old two-step tuple before adding MOLD_VERIFY_STEP to it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): anchor the toolchain-default regex to the toolchain input block validate_toolchain_pin_sync() used `re.search(r'default:\s*"([^"]+)"', action_text)` over the WHOLE setup-rust action.yml, resolving to the first non-empty `default:` in the file. That is only ever the `toolchain` input's default by accident — every other input's default is an empty string today and sits after it. A reordered or added input with its own non-empty default before `toolchain:` silently redirects the guard onto the wrong value, hiding real drift between rust-toolchain.toml and the composite. Add input_body(), a step_body-style helper that bounds one action.yml `inputs:` entry by the next input heading, and scope the default-value search to the `toolchain:` input's own block. Regression: added test_a_reordered_earlier_input_with_a_non_empty_default_cannot_hide_drift, confirmed it failed against the old whole-file regex (a decoy default matching the pinned channel hid an actual drift in toolchain's own default) before scoping the search to input_body(). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): catch workflow-level env RUSTFLAGS shadowing setup-rust too JOB_ENV_RUSTFLAGS matched only six-space job-level `env:` indentation (jobs.<job>.env.RUSTFLAGS). A workflow-level top `env:` block shadows the composite's mold export identically — GitHub re-applies it to every step of every job the same way it re-applies job-level env — but sits at two-space indentation before any job heading, so it was invisible both to the indentation-bound regex and to the per-job block slicing (which only starts scanning at each job heading). Add a WORKFLOW_ENV_RUSTFLAGS check over the file's preamble alongside the existing per-job scan. Also add the missing PER-JOB skip coverage: the only existing test for `SETUP_RUST_USES not in block` exercised the FILE-level skip (`SETUP_RUST_USES not in text`) via a single-job file. Added a same-file two-job test where one job uses the composite and a sibling does not, to prove the sibling's own RUSTFLAGS stays allowed. Regression: added test_workflow_level_rustflags_alongside_setup_rust_fails, confirmed it failed before adding the WORKFLOW_ENV_RUSTFLAGS preamble check, then restored it green; also added test_sibling_job_without_setup_rust_is_allowed_in_a_multi_job_file to pin the previously-untested per-job skip branch. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * test(ci): assert every exhaustive-plan field for the setup-rust widen test_shared_setup_rust_action_widens_to_exhaustive_plan only checked 4 of the 11 fields _full_plan() returns (mode, root_partitions, integration_lanes, and a substring of reasons[0]) — the other 7, including run_sandbox_docker and run_group_tests, were unpinned. This is ws12's own guardrail framework, so a regression narrowing this exact plan's blast radius deserved full coverage, not a partial one. Regression: widened the assertion to full dict equality against every field _full_plan() returns; confirmed it fails when run_sandbox_docker is flipped to False (a change the old partial assertion would have let through silently), then restored it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): glob both .yml and .yaml when loading workflows load_workflows() globbed only `*.yml` under .github/workflows/. GitHub Actions accepts either extension for a workflow file, so a `.yaml` workflow would silently escape every ws12 contract this loader feeds — latent today since no `.yaml` workflow exists, but a landmine for the next one added. Glob both extensions. Regression: added test_discovers_both_yml_and_yaml_extensions, confirmed it failed against the *.yml-only glob (the .yaml fixture was silently dropped) before widening the glob. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): guard every Rust bootstrap, not just the vendor action An approach audit found the migration's "single owner" claim was false and, worse, unenforceable: .github/workflows/ironclaw-release.yml:133 still bootstraps Rust with `curl https://sh.rustup.rs | sh`, so the lane that builds shipped artifacts got no RUSTUP_TOOLCHAIN pin, no mold wiring and no check against rust-toolchain.toml. validate_no_direct_dtolnay_usage greps only the literal `dtolnay/rust-toolchain@`, so that path passed the gate forever, and no test covered it. The file is live, not inert boilerplate — commit2a7d49c60hand-edited that exact line five days before this branch. That file is regenerated wholesale by cargo-dist (see [workspace.metadata.dist], cargo-dist-version 0.31.0), so migrating it onto the composite would be clobbered on the next regeneration. It is therefore an ACCEPTED exception rather than a silent one: - validate_no_unmanaged_rust_bootstrap now fails on `sh.rustup.rs`, `rustup-init` and `rustup toolchain install` in any workflow, with ACCEPTED_RUST_BOOTSTRAPS pinning ironclaw-release.yml to exactly one occurrence. A second bootstrap there, or any in a hand-written workflow, fails the gate; and if the generator stops emitting it, the count check says so instead of leaving a stale exemption behind. - AGENTS.md and rust-toolchain.toml said "every CI job" and "exclusively". Both were false as written. They now say hand-written jobs, name the exception, and point at the checker that enforces it. Proven by sabotage: adding a curl bootstrap to code_style.yml fails the gate; adding a SECOND one to ironclaw-release.yml fails it with "2 ... 1 accepted here"; both restored, gate green. Five unit tests cover the hand-written case, rustup-init/toolchain-install variants, the accepted single, the accepted-file second, and the live tree. Also drops INPUT_HEADING/input_body, a byte-identical duplicate of the existing JOB_HEADING/job_body with one call site — an action's `inputs:` entry has the same two-space `name:` shape a workflow job does, so job_body(action_text, "toolchain") does the job. Verified: ws12 self-tests 120 OK, ws12 live gate passed, planner suite 88 OK, check-guidance OK. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(toolchain): name the accepted release-workflow bootstrap in the pin header The companion commit corrected AGENTS.md but this file's header still said "CI workflows install Rust exclusively through .github/actions/setup-rust" — false while ironclaw-release.yml bootstraps Rust itself, and the same overstatement the audit flagged. (The earlier edit aborted on an unrelated assertion before reaching this file.) It now says hand-written workflows, and names the one accepted exception plus the checker that pins it to a single occurrence, so the header matches what the gate actually enforces. Verified: check-guidance OK, ws12 live gate passed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): migrate the release lane onto the composite and unbreak two guards An approach re-audit and a multi-agent code review both rejected the previous round's work. Three real defects, all in code added by this PR. 1. The "accepted exception" was unjustified. The claim was that cargo-dist regenerates ironclaw-release.yml wholesale, so its `curl sh.rustup.rs` bootstrap could not be migrated. The repo contradicts that four ways: `allow-dirty = ["ci"]` exists precisely so hand-edits survive regeneration (.github/workflows/README.md documents it for the permission hardening); two other hand-added steps already live in that job; cargo-dist exposes `github-build-setup` (already used for Node/pnpm in .github/dist-build-setup.yml) as the durable seam for exactly this; and `actions/checkout` and `setup-python` already run via `uses:` in that same container job, so a composite call is not structurally precluded. The bootstrap now lives in .github/dist-build-setup.yml as a `uses: ./.github/actions/setup-rust` call, re-included on every regeneration, keeping the previous step's `if: ${{ matrix.container }}` condition so release behaviour is unchanged. ACCEPTED_RUST_BOOTSTRAPS is empty: no lane is exempt, and the prose in AGENTS.md and rust-toolchain.toml states that without carve-outs because it is now true. 2. The workflow-level RUSTFLAGS check was dead code. JOB_HEADING matches any two-space `key:` line, so `on:`'s children (`push:`, `workflow_call:`) matched and headings[0] truncated the preamble at the first TRIGGER — before the real top-level `env:`. Verified on the live reborn-tests.yml: first match was `workflow_call` at offset 26, `jobs:` at 3177. Headings are now bounded to the `jobs:` block. The old unit test passed only because its fixture omitted `on:`; the new one carries a realistic trigger block. 3. The per-job check was blind to YAML aliases. release-plz.yml's `release-plz-pr` reaches the composite via `- *install-rust` and contains no literal `uses:` line, so the scan skipped it — a job-level RUSTFLAGS there would have shadowed mold silently. Anchors carrying the composite are now resolved and aliased jobs are checked. Also broadens the bootstrap guard beyond three rustup literals to known third-party toolchain actions (actions-rs, actions-rust-lang, hecrj, raftario), after the coverage lane showed the enumeration was trivially evadable. The one case text cannot see — a `container:` image shipping Rust preinstalled — is named in a comment as residual risk rather than papered over. Proven against the real files that defeated the old guards: a workflow-level RUSTFLAGS injected into reborn-tests.yml is now caught; a job-level RUSTFLAGS in release-plz.yml's alias-reached job is now caught; both were silent before. Also removes an orphaned comment left describing the deleted INPUT_HEADING. Verified: ws12 self-tests 123 OK, ws12 live gate passed, planner suite 88 OK, check-guidance OK, both changed workflows parse. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): catch step-level RUSTFLAGS, not just job- and workflow-level Third gap the review found in the same guard. JOB_ENV_RUSTFLAGS matched the exact 6-space job-env depth, but GitHub also lets an individual step declare `env:` (10 spaces in this repo's workflows, e.g. reborn-tests.yml:255), and a step-level RUSTFLAGS shadows the composite's $GITHUB_ENV write for that step exactly like a job-level one — dropping the mold linker flags with no failing check, which is the precise regression the guard exists to prevent. Widened to `^ {6,}RUSTFLAGS:` so job- and step-level depths are both caught, and corrected the error message, which called a step-level key "job-level". Proven against the live file: injecting a step-level RUSTFLAGS into reborn-tests.yml's crate-tests job is now reported; the clean tree still passes, so the wider pattern adds no false positives. Worth stating plainly: this is the third hole found in this one substring-matching guard (dead workflow-level check, alias blindness, now step-level depth). Enforcement by grepping YAML text is structurally weaker than the composite's own RUSTUP_TOOLCHAIN export, which makes drift unrepresentable rather than policed. The stdlib-only constraint on scripts/ci rules out a real YAML parse here, so the residual risk is the shapes no pattern anticipated — noted rather than claimed away. Verified: ws12 self-tests 124 OK, ws12 live gate passed, planner suite 88 OK. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): restore the release lane's Rust install and assert it is there The previous commit broke the release lane. It deleted the container-only `curl | sh` bootstrap from .github/workflows/ironclaw-release.yml and added the composite call only to .github/dist-build-setup.yml — but that fragment reaches the generated workflow solely through `dist generate`, which was never run. The checked-in workflow ended up with NO Rust install path at all: `grep -c 'setup-rust|Install Rust|rustup' ironclaw-release.yml` → 0. The next tagged release would have failed on `cargo: command not found` in every container matrix entry — the exact case the deleted step existed for. Two independent code-review lanes caught it (Critical/confidence 100 and High/confidence 92), both noting the same root cause: every check in this file asserts an ABSENCE — no dtolnay, no raw bootstrap, no shadowing RUSTFLAGS — so deleting a step and adding nothing read as "clean" and the whole suite stayed green over a broken release lane. The step is now in both places, deliberately: the fragment so `dist generate` keeps emitting it, and the checked-in workflow because that is the file GitHub actually runs. validate_release_workflow_installs_rust closes the class by asserting PRESENCE in both files. Proven red-first in both directions: removing the step from the generated workflow fails with the cargo-not-found rationale; removing it from the fragment fails with the regeneration rationale; restoring either passes. Four unit tests plus a live-tree assertion. This is the second time in this PR that an absence-only guard reported success over a real defect. Guards that only forbid shapes cannot notice that the thing they were protecting is gone. Verified: ws12 self-tests 128 OK, ws12 live gate passed, planner suite 88 OK, ironclaw-release.yml parses. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(ci): split the Rust toolchain contracts out of ws12_workflow_contracts Pure move, no behavior change. ws12_workflow_contracts.py had grown to 2,171 lines — past the repo's ~1k ceiling — mixing stress-suite parity, crate scope filters, WebUI site checks, and this PR's six toolchain validators in one file. Three separate reviews flagged it (two approach audits, one design lane). scripts/ci/lib/rust_toolchain_contracts.py now owns one question: what toolchain, linker, and build flags does a Rust job get? Six validators, their constants, and a module docstring recording the absence-vs-presence asymmetry that let a release workflow with no Rust install pass this suite last week. scripts/ci/lib/workflow_text.py owns the four generic YAML text helpers both modules need. This absorbed a latent defect: JOB_HEADING was defined TWICE in ws12 (lines 426 and 988), the second shadowing the first for every validator below it. The two patterns were `[A-Za-z0-9_-]` and `[a-zA-Z0-9_-]` — semantically identical, so nothing was wrong today, but only by luck. One definition now. The test file imports each symbol from its owning module rather than letting ws12 act as an implicit re-export, so the ownership is checkable. classify-test-scope.sh: both new paths join the reborn-scoped list. Without this the split would have silently changed CI behavior — editing a validator in its new home would classify differently than editing it in ws12 did — which is exactly the kind of quiet regression a "pure move" is supposed to not have. test-classify-test-scope.sh pins it; proven red-first by reverting the list entry and watching the new assertion fail. Verified after the move, both validators proven to still fire from their new home by sabotage: breaking the RUSTUP_TOOLCHAIN export fails the gate, and deleting the release workflow's composite step fails it with the cargo-not-found rationale. ws12 self-tests 128 OK, live gate passed, classify-test-scope 69 PASS / 0 FAIL, check-guidance OK. ws12_workflow_contracts.py: 2171 -> 1833 lines. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(agents): point the toolchain pin at its owner instead of restating it The AGENTS.md paragraph and rust-toolchain.toml's header had grown into two near-verbatim copies of the same rationale — rustup precedence, the nightly coverage-lane carve-out, the cargo-dist fragment, why Docker is unaffected. Two copies of a rationale drift; the one nobody edits goes stale silently. AGENTS.md keeps what an agent needs to act: the pin is the source of truth, never install Rust in a workflow directly, and bumping is a two-place edit in one PR. The why lives in rust-toolchain.toml's header, where it sits next to the value it explains. 17 lines -> 11. Also refreshes the enforcement pointer to the module that now owns those checks after the split, and mentions the two guards added since this paragraph was written (release-lane presence, RUSTFLAGS shadowing). Verified: check-guidance OK (2603 path references, including the new scripts/ci/lib/rust_toolchain_contracts.py), ws12 gate passed, 128 self-tests OK. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): require every cargo job to reach the composite, not just the release lane A review lane proved the release-lane guard was the right fix written too narrowly. It verified the escape by mutation: delete the `uses: ./.github/actions/setup-rust` step from code_style.yml's fast-checks job — no dtolnay call, no raw bootstrap, no RUSTFLAGS key — and all 128 tests stayed green. That is the identical bug the release-lane guard was added for last commit, reproduced in a different file, because "no dtolnay, no bootstrap, no shadowing RUSTFLAGS" is trivially true of a job that installs nothing at all. validate_rust_jobs_reach_the_composite generalizes the rule: any job whose steps invoke cargo/rustc/rustup must reach the composite, directly or through a YAML alias. Scoped to jobs that actually run the compiler, so docs and frontend jobs need no exemption, and `Cargo.toml` in a `paths:` filter is not an invocation. It ships with NO allowlist because it needs none — all 31 cargo-running jobs in the tree satisfy it today. An entry here would mean a lane building Rust on whatever toolchain the runner image happens to ship. Proven red-first on the reviewer's exact mutation: the release-only guard reports 0 errors on it, the new one names all three affected jobs (fast-checks, clippy, clippy-windows). Six unit tests including the alias path and a live-tree assertion. Also in this commit, both from the same review: - workflow_text.py still defined JOB_HEADING twice. My split moved the duplicate instead of removing it, so the commit message claiming consolidation was wrong. One definition now, and a test asserts each pattern is bound exactly once — the shadowing itself is now what fails, not just today's instance of it. - The module docstring claimed five validators assert an absence. Three do. The other four assert presence or equality and are deletion-safe for their own subject. An inaccurate tally in the very docstring warning about this asymmetry is worth more than a typo. The job/anchor scan the RUSTFLAGS validator had inline is now shared with the new check (_composite_anchors / _job_blocks / _reaches_composite) rather than written twice. Verified: 137 self-tests OK, live gate passed, check-guidance OK, classify-test-scope 70 PASS / 0 FAIL. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): classify the cargo-dist fragment so the plan step stops failing closed This PR's own CI was red on `Build affected-area test plan`, and the cause was this PR: it edits `.github/dist-build-setup.yml`, the planner had no rule for that path, and the planner fails closed on anything unclassified. The step died before scheduling a single lane — so a PR touching only CI plumbing could not report at all. Reproduced locally with the exact CI invocation over the PR's real changed-file list: "Reborn PR test planner failed: unclassified pull-request path: .github/dist-build-setup.yml". Green after the fix, plan mode `full`. The fragment is workflow source that lives outside `.github/workflows/`: cargo-dist re-inlines it into `ironclaw-release.yml` on every `dist generate`. So it is the same static control as the file it becomes, and no Reborn lane reads it. That is exactly the `pull_request_template.md` gap the suite already pins, one directory over. A sweep test over the surfaces that make CI run then found a second, older gap: `.github/actions/install-cargo-component/action.yml` has been unmapped since it was introduced, so any PR editing it hits the same dead plan step. It is consumed by coverage.yml and platform-and-compat.yml, so it takes the exhaustive plan like its two siblings — the deliberate mapping that arm's own comment asks for. The sweep is scoped to `.github/actions/**` plus the fragment, NOT all of `.github/`. Fail-closed on an undecided path is this planner's intended behaviour and an existing test pins `.github/labeler.yml` refusing on purpose; a wider sweep contradicted it. The line is between config someone may leave undecided and source a job runs. Reported, not silently mapped: `.github/labeler.yml` and six `.github/scripts/*` helpers still refuse. `ci-job-result-ok.sh` is invoked by workflows, so it is a latent break of the same class — but mapping it is a policy call for the planner's owner, not a drive-by in this PR. Both fixes proven red-first: removing either mapping fails the suite, restoring either passes. Verified: planner 90 OK, ws12 137 OK, ws12 gate passed, staged-paths 4 OK, classify-test-scope exit 0, check-guidance OK, and the previously-red CI command now exits 0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(ci): close the three open audit findings All three were NORMAL, none blocking; closing them so review sees the design rather than a list of known nits. **One owner for the debug-info policy** (converged finding, reported independently by both system-audit lanes). The migration deleted these env pairs from five workflow job envs on the strength of Cargo.toml's `[profile.dev] debug = 0` owning the value — but left the identical `:-0` defaults standing in scripts/ci/quality_gate.sh and reborn-local-coverage-ratchet.sh. The PR's own claim of a single owner was not true of the tree it shipped. Both removed; no behaviour change, the values already agreed, and a developer's `CARGO_PROFILE_DEV_DEBUG=2` still reaches cargo because `env` inherits what it does not override. Deleting the lines alone would just let them come back, so `validate_single_debug_policy_owner` makes it structural: no script under scripts/ may ASSIGN a CARGO_PROFILE_*_DEBUG value. Assignments only — run-hermetic-test-process.sh names the same variables in a passthrough allowlist (a `case` pattern, no `=`), which is exactly how that override survives the hermetic barrier, and matching it would break the documented escape hatch. Test files are skipped: they carry the string on purpose as fixtures, and scanning them would make the contract untestable. **No speculative escape hatch.** `ACCEPTED_RUST_BOOTSTRAPS` was a per-path override with symmetric over-use AND under-use validation, plus a test pinning it empty — built in full for a case the module's own comment says does not exist. Removed; the rule is now unconditional. If an unavoidable bootstrap ever appears, the hatch gets added then, with that lane as its first entry. The test that asserted the dict stays empty now asserts the mechanism is gone rather than merely empty. **One job-boundary walk.** `_job_blocks` reimplemented the slice-between- consecutive-headings logic that `extract_job_block` already did in the same subsystem. `job_blocks()` in workflow_text.py is now the single primitive: `extract_job_block` filters it to one named job and keeps its exactly-one refusal, and the toolchain contracts enumerate it from the `jobs:` offset. That offset is load-bearing and stays — JOB_HEADING matches any two-space key, so an unbounded walk treats `on:`'s children as jobs. Verified: ws12 141 tests OK, live gate passed, planner 90 OK, staged-paths 4 OK, classify-test-scope exit 0, check-guidance OK, both edited shell scripts pass `bash -n`. The debug-policy guard proven red-first by restoring one deleted line and watching the gate name it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Address PR review feedback (#7821) Four threads triaged as valid and fixed. Two are real guard bypasses in the module this PR introduces — a reviewer reproduced both, and both are the same species the module's own docstring warns about: a check reading text that only LOOKS like an executable step, or reading too narrow a slice of the file. - **Release check was file-wide, not job-scoped.** Deleting the composite step from `build-local-artifacts` while a decoy `# uses: ...` comment sat in an unrelated job returned no error. That matters more than it looks: nothing in ironclaw-release.yml matches a literal `cargo` (cargo-dist shells out to `dist build`), so `validate_rust_jobs_reach_the_composite` never covers that file and this was its only guard. Now scoped to the job, and every `uses:` match is comment-stripped per line. - **Anchor scope ran past its own YAML node.** `_composite_anchors` scanned from an anchor to the next anchor or job heading, so a comment mentioning the composite anywhere in that span marked the anchor as installing Rust — and a job that merely aliased it passed while installing nothing. Bounded by indentation to the anchor's own node, and comment-stripped. The legitimate release-plz alias shape keeps working (pinned by its own test). - **Root-level `env:` after `jobs:` was invisible.** A top-level mapping key need not precede `jobs:`; such a block applies to every job identically, but slicing the preamble at `jobs:` hid it while its two-space indent also dodged the six-space per-job pattern. It fell through both checks. Now scans the whole file. - **AGENTS.md overstated the contract.** My earlier commit463b02974made this paragraph MORE absolute than the one it replaced — "single source of truth" and "every job" — when there are two synchronized pins checked for equality, neither derived from the other, plus a nightly-lane carve-out and Docker outside the contract entirely. That is the exact universal-claim pattern `.claude/rules/guidance-maintenance.md` forbids. Reworded to say what is actually enforced. Test-file changes and why: - `ReleaseWorkflowInstallsRustTests` gained a `release()` helper and its fixtures now name `build-local-artifacts`. The old fixtures were a bare `jobs:\n build:` which no longer exercises a job-scoped contract. This makes the fixture match the real workflow shape; it does not relax an assertion. - `GuardBypassRegressionTests` adds four tests: one per bypass, plus one pinning that a real anchor alias still passes so the anchor fix cannot be "fixed" by rejecting legitimate aliases. All three code fixes proven red-first: reverting each one individually fails its own regression, and restoring it passes. Verified: ws12 145 tests OK, live gate passed, planner 90 OK, staged-paths 4 OK, classify-test-scope exit 0, check-guidance OK. Not addressed here, reported on the threads: the `workflow_dispatch` + local-action-resolution regression needs a design call (20+ sites, 4 workflows), and one thread's claim was already fixed earlier in this branch. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): install Rust in the one hermetic lane that acquired it lazily Root cause of the E2E failures that have been red on every run of this branch while T2/T3/T4 from the same base are green. `webui-v2-test-lanes` runs a prebuilt binary and compiles nothing, so it never installed Rust. But `run-hermetic-test-process.sh` probes `rustc --print sysroot` to build the child PATH and exits 1 if it cannot resolve one. Inside the repo that probe hits the `rust-toolchain.toml` this PR adds, so rustup installed the pinned toolchain LAZILY — mid-lane, once per shard, racing its own component downloads: provider operation shard 2/4 failed with status 1 error: component download failed for rustfmt-x86_64-unknown-linux-gnu: could not rename 'downloaded' file ... .partial Confirmed by controlled experiment (#7852): reverting only `[profile.dev] debug = 0` and keeping everything else left E2E red, with a DIFFERENT subset of shards failing — a race signature, and it exonerates the profile block. A survey of every lane invoking the hermetic runners found exactly one in this state; the other seven already install through the composite. So this is one missing step, not a design fault — but it was invisible because the lane compiles nothing, and the whole point of this PR is that toolchain acquisition should never be implicit. `validate_rust_jobs_reach_the_composite` now treats a hermetic-runner invocation as needing a toolchain, the same as a literal `cargo` line. It could not see this before: the workflow text only names the script. Proven red-first — removing the step again fails the gate by name. I called this failure an unrelated rustup flake twice. It was neither: it was this PR's own side effect, visible in the logs from the first run. Verified: ws12 147 tests OK, live gate passed, planner 90 OK, classify-test-scope exit 0, check-guidance OK, reborn-e2e.yml parses. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): realign the assertion I broke by rewording the guard message The previous commit widened `validate_rust_jobs_reach_the_composite` to cover hermetic lanes and reworded its message from "runs cargo but never reaches" to "needs a Rust toolchain but never reaches" — but an existing test still asserted the old string. Fast-checks went red, and Code Style followed it ("fast-checks failed: failure"), so both new failures had this one cause. Worth recording HOW it shipped, because the mistake was in my verification and not in the edit. The combined-validation command was: python3 scripts/ci/test_ws12_workflow_contracts.py 2>&1 | tail -3 | head -2 `tail -3` yields ["Ran N tests in Xs", "", "OK|FAILED"]; `head -2` then drops the verdict line. The output read "Ran 147 tests in 12.705s" and I took that as a pass. The suite had already been failing locally at that point — the command was constructed so it could not tell me. Validation now keys off exit codes rather than parsed tail text, so a failing suite cannot render as a passing one. Verified (exit codes): ws12 self-tests 0, ws12 gate 0, planner 0, staged-paths 0, suite-shards 0, changed-packages 0, classify-test-scope 0, check-guidance 0, docs-boundary 0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): make the debug-policy guard see where the value was actually written Two review lanes independently reported that `validate_single_debug_policy_owner` cannot detect the regression it exists to prevent, and they are right. The guard scanned `scripts/**` for `KEY=value`. This PR deleted 14 `CARGO_PROFILE_*_DEBUG` lines from `.github/workflows/**`, all in YAML `KEY: value` form. So the guard covered the 3 script-side deletions and was blind to the 14 workflow-side ones — the majority of what it was written to keep deleted. A future PR re-adding a job-env pair would have passed clean. Reproduced before fixing: a scratch tree with a workflow job env containing `CARGO_PROFILE_DEV_DEBUG: 0` returned zero errors, and the regex did not match the YAML form at all. Now scans `scripts/**` and `.github/**` across .sh/.py/.yml/.yaml, and matches both `=` and `:`. Verified the widening is safe: nothing in the live tree matches, and the `run-hermetic-test-process.sh` passthrough allowlist still does not — that entry is a `case` pattern with no assignment character after the name, and it is how a developer's `CARGO_PROFILE_DEV_DEBUG=2` override reaches the child process. A test now pins that it keeps working. Proven red-first in both directions independently: narrowing the scope back to `scripts` fails the two workflow tests; narrowing the syntax back to `=` fails the same two. This is the third time in this PR that a guard I wrote asserted something narrower than the thing it was protecting. The pattern is consistent enough to name: I write the check against the case that prompted it rather than against the invariant, and the surrounding cases go uncovered. Also adds the widening test for `.github/actions/install-cargo-component/` (coverage lane, low severity). Its two sibling shared actions each had one; this path had only the `.github/actions/**` sweep, which asserts the planner does not RAISE but never checks the mode it returns — a mis-ordering could drop it to a `none` plan and the sweep would still pass. Red-first: removing the prefix entry fails the new test. Not changed, with measurements: a performance lane flagged the `Install Rust` step added to the 4 binary-only E2E shards as avoidable cost. Measured on the green run, it is 9-11s per shard on parallel runners, and it replaces a toolchain install that was already happening implicitly inside the test step while racing itself. Removing it entirely means changing the sysroot probe in run-hermetic-test-process.sh, which 8 lanes share. Not worth that risk for ~10s; recorded as a possible follow-up. Verified (exit codes): ws12 150 tests 0, ws12 gate 0, planner 91 tests 0, staged-paths 0, suite-shards 0, changed-packages 0, classify-test-scope 0, check-guidance 0, docs-boundary 0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(agents): replace a universal claim with a verified, re-checkable count `.claude/rules/guidance-maintenance.md` rule 3 forbids universal claims without a count, and rule 2 asks for a one-line command a maintainer can re-run. The paragraph said "Every Rust-installing CI job goes through the composite" — an uncounted absolute. Pointedly, this sentence was introduced by MY fix for the previous universal-claim finding on this same paragraph. I removed "single source of truth" and "every job" from one clause and wrote a fresh absolute into the next. Now: "35 CI jobs across 11 workflow files need a toolchain and all 35 reach the composite today, with no allowlist", plus the command that re-derives it and the validator that enforces it. Counted at this head by walking every job block and testing for a cargo/rustc/rustup invocation or a hermetic-runner call; 35 need one, 35 reach it. Verified (exit codes): check-guidance 0, ws12 gate 0, ws12 self-tests 0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): pin the release step's condition, and scope the coverage claim to it From your review (#7821 review 5012242062), Medium/86 on the release matrix. The valid core: the contract asserted the composite step's TEXT existed in `build-local-artifacts` and said nothing about WHEN it runs. `if: ${{ matrix.container }}` decides which matrix entries reach the composite at all, so it could be narrowed, widened, or dropped and no check would notice — while this PR claimed every Rust job reaches the composite. Now pinned in both the generated workflow and `.github/dist-build-setup.yml`, since a mismatch is what `dist generate` would silently apply. Proven red-first in both directions: changing the condition names the old and new values; dropping it reports `<unconditional>`. Three regressions, plus the existing fixtures updated to carry the condition (they previously wrote a bare step, so they could not have exercised this). One part of the finding I checked and do not think holds. It says a non-container release build "bypasses the new pin/export path and relies on whatever Rust the hosted runner provides". The pin is not bypassed: with `rust-toolchain.toml` in the repo, rustup resolves it when `dist build` invokes cargo on the hosted runner. What those entries miss is mold and the explicit `RUSTUP_TOOLCHAIN` export, not the toolchain version. It is also not a regression — the pre-composite step carried the identical `if: ${{ matrix.container }}`, so release behaviour is unchanged by this PR. Where the finding lands hardest is the docs, and that is my error. AGENTS.md said "35 CI jobs ... all 35 reach the composite" — true for what it counts, but the count walks `.github/workflows` only and the release lane is outside it entirely (no job there names `cargo`; it shells out to `dist build`). A reader would have taken it as universal. That is the second time in two commits I replaced a universal claim with another one. Now scoped explicitly, naming the release lane's actual shape and what the non-container entries do and do not get. Open question I am not deciding here: whether non-container release builds should install explicitly rather than resolving the pin lazily. That is a release-path behaviour change on a Track C surface, and the lazy resolution is the same mechanism that raced in the E2E lanes — lower risk here (no parallel shards within the job) but still implicit. Verified (exit codes): ws12 153 tests 0, ws12 gate 0, planner 0, classify-test-scope 0, check-guidance 0, docs-boundary 0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): close four review findings on the condition and debug-policy guards Two Major, both real, both in code I added in the previous two commits. **The condition check had a false positive on the release path.** `_composite_step_condition` scanned only the lines ABOVE the composite `uses:` line. YAML mapping keys are unordered, so a step written `uses:` then `if:` is valid and equivalent — and returned None, reporting `<unconditional>` and rejecting a correct release workflow. Reproduced directly: the reordered step returned None. Now bounded by the step's own `- ` marker and the next line at or left of it, so the whole step body is scanned. Regression both ways: the reordered step passes, and a neighbouring step's `if:` is still not borrowed. **Quoted YAML keys bypassed the debug-policy guard.** `"CARGO_PROFILE_DEV_DEBUG": 0` and `'CARGO_PROFILE_DEV_DEBUG': 0` are the same mapping key as the bare form and matched nothing. Fixed with an optional quote on either side; the `run-hermetic-test-process.sh` passthrough allowlist still does not match, which a test pins. Two smaller ones on the test I added last commit, both correct: - the fail-closed case still probed `.github/actions/setup-rust/` — a leftover from mirroring the sibling test, so it re-tested the sibling's invariant instead of this one. Now probes install-cargo-component. - ISC004 implicit string concatenation in the expected `reasons` list. All three code fixes proven red-first: reverting the whole-step scan fails the reordered-step test; reverting the quoted-key regex fails both quoted forms; removing the prefix entry fails the mirrored test. Pattern worth recording, since it is now consistent. Both Major findings are the same shape as the three before them: I wrote each check against the exact shape in front of me — `if:` before `uses:`, an unquoted YAML key — rather than against the invariant, and the neighbouring valid shapes went unhandled. The guards keep being narrower than the thing they protect. External review has caught every instance; my own tests passed over all of them, because I wrote the tests from the same narrow mental model as the code. Verified (exit codes): ws12 156 tests 0, ws12 gate 0, planner 91 tests 0, check-guidance 0, classify-test-scope 0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Henry Park <16583448+henrypark133@users.noreply.github.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
589 lines
28 KiB
Python
589 lines
28 KiB
Python
#!/usr/bin/env python3
|
|
"""Contracts for the single Rust toolchain setup path.
|
|
|
|
One question, one module: *what toolchain, linker, and build flags does a
|
|
Rust job get?* The answer is `.github/actions/setup-rust` and nothing else,
|
|
and these six validators are what make that true rather than aspirational.
|
|
|
|
Split out of `ws12_workflow_contracts.py`, which had grown past 2,100 lines
|
|
covering unrelated lanes (stress suites, crate scope filters, WebUI sites).
|
|
Wiring stays in that module's `validate_workflow_texts`; only the
|
|
toolchain-shaped rules live here.
|
|
|
|
Note which direction each check runs, because the mix is what makes the
|
|
suite trustworthy. Three assert an ABSENCE — no dtolnay action, no raw
|
|
bootstrap, no shadowing RUSTFLAGS key. Absence-only guards cannot notice that
|
|
the thing they protect has been deleted: a job that installs nothing at all
|
|
satisfies every one of them. That is exactly how a release workflow with no
|
|
Rust install passed this suite.
|
|
|
|
The other four assert a PRESENCE or an equality and are therefore
|
|
deletion-safe for their own subject: the composite has the steps it must have,
|
|
its default equals rust-toolchain.toml's channel, the release lane and its
|
|
cargo-dist fragment both reach the composite, and every job that runs cargo
|
|
reaches it. Before adding an eighth, work out which direction it runs and what
|
|
deletion it would miss.
|
|
"""
|
|
|
|
from __future__ import annotations
|
|
|
|
import re
|
|
from pathlib import Path
|
|
|
|
from workflow_text import JOB_HEADING, job_blocks, job_body, step_body
|
|
|
|
ROOT = Path(__file__).resolve().parents[3]
|
|
|
|
SETUP_RUST_ACTION = ".github/actions/setup-rust/action.yml"
|
|
RUSTUP_TOOLCHAIN_PIN_STEP = "Pin the resolved toolchain for the rest of this job"
|
|
MOLD_INSTALL_STEP = "Install mold and clang"
|
|
MOLD_VERIFY_STEP = "Verify mold linker is active"
|
|
MOLD_EXPORT_STEP = "Export mold RUSTFLAGS"
|
|
# The one canonical mold invocation; a job's own env may append extra flags
|
|
# after it (the nightly lanes add -Zcrate-attr=...), but this prefix is the
|
|
# only place it may be written out — everywhere else must go through here.
|
|
MOLD_RUSTFLAGS = "-C linker=clang -C link-arg=--ld-path=/usr/bin/mold"
|
|
|
|
|
|
def validate_setup_rust_action(text: str | None) -> list[str]:
|
|
"""The setup-rust composite must actually pin RUSTUP_TOOLCHAIN and mold.
|
|
|
|
Contract: every job that installs Rust through this composite gets a
|
|
RUSTUP_TOOLCHAIN export naming exactly the toolchain dtolnay/rust-toolchain
|
|
just installed (steps.install.outputs.name — not a second, possibly wrong,
|
|
guess at the resolved version), and mold's install/verify/RUSTFLAGS steps
|
|
are gated on Linux so `mold: true` is safe to pass on any runner OS.
|
|
"""
|
|
if text is None:
|
|
return [f"{SETUP_RUST_ACTION}: could not read the composite action file"]
|
|
errors: list[str] = []
|
|
pin_step = step_body(text, RUSTUP_TOOLCHAIN_PIN_STEP)
|
|
if pin_step is None:
|
|
errors.append(
|
|
f"{SETUP_RUST_ACTION}: missing the {RUSTUP_TOOLCHAIN_PIN_STEP!r} step"
|
|
)
|
|
elif "RUSTUP_TOOLCHAIN=${{ steps.install.outputs.name }}" not in pin_step:
|
|
errors.append(
|
|
f"{SETUP_RUST_ACTION}: {RUSTUP_TOOLCHAIN_PIN_STEP!r} must export "
|
|
"RUSTUP_TOOLCHAIN from steps.install.outputs.name, or a job's "
|
|
"cargo invocations can drift from what this step actually installed"
|
|
)
|
|
for step_name in (MOLD_INSTALL_STEP, MOLD_VERIFY_STEP, MOLD_EXPORT_STEP):
|
|
body = step_body(text, step_name)
|
|
if body is None:
|
|
errors.append(f"{SETUP_RUST_ACTION}: missing the {step_name!r} step")
|
|
continue
|
|
if "runner.os == 'Linux'" not in body:
|
|
errors.append(
|
|
f"{SETUP_RUST_ACTION}: {step_name!r} must gate on "
|
|
"runner.os == 'Linux' so mold: true is safe on any runner"
|
|
)
|
|
export_step = step_body(text, MOLD_EXPORT_STEP)
|
|
if export_step is not None and MOLD_RUSTFLAGS not in export_step:
|
|
errors.append(
|
|
f"{SETUP_RUST_ACTION}: {MOLD_EXPORT_STEP!r} must export the "
|
|
f"canonical mold RUSTFLAGS prefix '{MOLD_RUSTFLAGS}'"
|
|
)
|
|
return errors
|
|
|
|
|
|
DTOLNAY_ACTION = "dtolnay/rust-toolchain@"
|
|
|
|
|
|
def validate_no_direct_dtolnay_usage(workflows: dict[str, str]) -> list[str]:
|
|
"""Every workflow must install Rust through .github/actions/setup-rust.
|
|
|
|
A negative substring check, not a per-site window scan: this is what
|
|
T1's earlier per-input-drift design collapsed to once every job routes
|
|
through one composite. Also forbids re-writing out the canonical mold
|
|
RUSTFLAGS prefix by hand anywhere a workflow's own env block might set
|
|
it — the composite is the only place that string may appear.
|
|
"""
|
|
errors: list[str] = []
|
|
for path, text in workflows.items():
|
|
if DTOLNAY_ACTION in text:
|
|
errors.append(
|
|
f"{path}: calls {DTOLNAY_ACTION!r} directly — install Rust "
|
|
"through .github/actions/setup-rust instead"
|
|
)
|
|
if MOLD_RUSTFLAGS in text:
|
|
errors.append(
|
|
f"{path}: writes out the canonical mold RUSTFLAGS prefix "
|
|
f"'{MOLD_RUSTFLAGS}' directly — pass mold: true to "
|
|
".github/actions/setup-rust instead, which prepends it onto "
|
|
"this job's existing RUSTFLAGS"
|
|
)
|
|
return errors
|
|
|
|
|
|
SETUP_RUST_USES = "uses: ./.github/actions/setup-rust"
|
|
JOBS_KEY = re.compile(r"^jobs:[ \t]*$", re.MULTILINE)
|
|
# One list item that is nothing but an anchor definition (`- &install-rust`).
|
|
# Matched per line so the node it opens can be bounded by indentation.
|
|
ANCHOR_DEF_LINE = re.compile(r"^\s*-\s*&(?P<name>[\w-]+)\s*$")
|
|
# Job-level `env:` (jobs.<job>.env, two-space job + four-space `env:` + this
|
|
# key at six spaces) and workflow-level top `env:` (two-space key straight
|
|
# under the file's own `env:`) are both re-applied to every step of a job on
|
|
# top of $GITHUB_ENV, so both shadow the composite's mold export the same
|
|
# way. They need separate patterns, not one merged indentation class: the
|
|
# workflow-level form sits in the file's preamble, before any job heading, so
|
|
# it is checked once per file rather than by slicing per-job blocks.
|
|
# Any RUSTFLAGS key inside a job, at job-env depth (6 spaces) or
|
|
# step-env depth (10) — a step-level env shadows the composite's
|
|
# $GITHUB_ENV write for that step exactly like a job-level one, so
|
|
# pinning the exact job depth left a third of the shapes unguarded.
|
|
JOB_ENV_RUSTFLAGS = re.compile(r"^ {6,}RUSTFLAGS:", re.MULTILINE)
|
|
WORKFLOW_ENV_RUSTFLAGS = re.compile(r"^ {2}RUSTFLAGS:", re.MULTILINE)
|
|
|
|
|
|
def validate_no_job_env_rustflags_with_setup_rust(
|
|
workflows: dict[str, str],
|
|
) -> list[str]:
|
|
"""A job installing Rust via the composite must not set its own RUSTFLAGS.
|
|
|
|
GitHub re-applies a job-level `env:` mapping to every step of that job,
|
|
on top of whatever earlier steps wrote to $GITHUB_ENV. So a job-level
|
|
`RUSTFLAGS:` shadows the composite's export for the rest of the job and
|
|
silently drops the mold linker flags — a slower build, never a red
|
|
check, which is exactly the drift class this action exists to remove. A
|
|
workflow-level top `env:` key shadows every job in the file identically,
|
|
so it is checked the same way. Jobs pass their extra flags through the
|
|
composite's `extra_rustflags` input instead, so one place composes the
|
|
final value.
|
|
"""
|
|
|
|
errors: list[str] = []
|
|
for path, text in workflows.items():
|
|
if SETUP_RUST_USES not in text:
|
|
continue
|
|
anchors = _composite_anchors(text)
|
|
# Whole file, not just the preamble. A top-level mapping key need not
|
|
# precede `jobs:` — a root `env:` block placed after it is valid YAML,
|
|
# applies to every job the same way, and slicing at `jobs:` made it
|
|
# invisible to this check while its two-space indent also dodged the
|
|
# six-space per-job pattern. It fell through both.
|
|
if WORKFLOW_ENV_RUSTFLAGS.search(text):
|
|
errors.append(
|
|
f"{path}: workflow-level env sets a RUSTFLAGS key while a "
|
|
"job in this file installs Rust through "
|
|
".github/actions/setup-rust — a workflow-level env key "
|
|
"shadows the composite's $GITHUB_ENV write for every job in "
|
|
"the file identically to a job-level one; pass extra flags "
|
|
"as the composite's extra_rustflags input instead"
|
|
)
|
|
for name, block in _job_blocks(text):
|
|
if not _reaches_composite(block, anchors):
|
|
continue
|
|
if JOB_ENV_RUSTFLAGS.search(block):
|
|
errors.append(
|
|
f"{path}: job {name!r} sets a job- or "
|
|
"step-level RUSTFLAGS env key while installing Rust through "
|
|
".github/actions/setup-rust — job env shadows the "
|
|
"composite's $GITHUB_ENV write and drops the mold linker "
|
|
"flags; pass them as the composite's extra_rustflags "
|
|
"input instead"
|
|
)
|
|
return errors
|
|
|
|
|
|
RUST_BOOTSTRAP_PATTERNS = (
|
|
# Raw rustup bootstraps.
|
|
"sh.rustup.rs",
|
|
"rustup-init",
|
|
"rustup toolchain install",
|
|
# Third-party toolchain actions. The composite is the only sanctioned
|
|
# installer, so a workflow reaching for a different vendor action is the
|
|
# same drift as a curl bootstrap: unpinned toolchain, no mold, no
|
|
# rust-toolchain.toml sync. (`dtolnay/rust-toolchain` has its own check
|
|
# with a more specific message; it is deliberately not repeated here.)
|
|
"actions-rs/toolchain",
|
|
"actions-rust-lang/setup-rust-toolchain",
|
|
"hecrj/setup-rust-action",
|
|
"raftario/setup-rust-action",
|
|
)
|
|
# Residual risk, named rather than papered over: a job whose `container:`
|
|
# image ships Rust preinstalled installs nothing, so no text pattern can see
|
|
# it. Such a job would silently build on the image's toolchain instead of the
|
|
# pin. Nothing in .github/workflows does this today; if one appears it needs a
|
|
# structural check (assert every Rust-building job calls the composite), not a
|
|
# wider substring list.
|
|
# No workflow may bootstrap Rust outside the composite. cargo-dist
|
|
# re-includes .github/dist-build-setup.yml on every regeneration, so the
|
|
# release build jobs install Rust through the composite from there — there
|
|
# is no lane this contract cannot cover, and so no exemption mechanism here.
|
|
# If a genuinely unavoidable bootstrap ever appears, add the escape hatch
|
|
# then, with that lane as its first entry and its reason in the comment.
|
|
|
|
|
|
def validate_no_unmanaged_rust_bootstrap(workflows: dict[str, str]) -> list[str]:
|
|
"""Every hand-written workflow installs Rust through the composite.
|
|
|
|
`validate_no_direct_dtolnay_usage` only sees the vendor action. A raw
|
|
`curl https://sh.rustup.rs | sh` installs Rust just as effectively and
|
|
matches no such string, so it would otherwise pass this gate forever --
|
|
unpinned, without mold, and unchecked against rust-toolchain.toml.
|
|
"""
|
|
|
|
errors: list[str] = []
|
|
for path, text in workflows.items():
|
|
hits = sum(text.count(pattern) for pattern in RUST_BOOTSTRAP_PATTERNS)
|
|
if not hits:
|
|
continue
|
|
errors.append(
|
|
f"{path}: {hits} raw Rust bootstrap(s) "
|
|
f"({', '.join(RUST_BOOTSTRAP_PATTERNS)}). Install Rust through "
|
|
".github/actions/setup-rust so the toolchain stays pinned, mold "
|
|
"stays wired, and rust-toolchain.toml stays enforced."
|
|
)
|
|
return errors
|
|
|
|
|
|
def _composite_anchors(text: str) -> set[str]:
|
|
"""Anchor names whose OWN YAML node reaches the composite.
|
|
|
|
A job can pick the composite up through an alias (`- *install-rust`)
|
|
rather than a literal `uses:` line, as release-plz.yml does, so both
|
|
contracts below have to resolve aliases before deciding a job misses it.
|
|
|
|
Bounded by indentation, and comment-stripped, because the previous span
|
|
("from this anchor to the next anchor or job heading") was wide enough to
|
|
swallow unrelated siblings: a *comment* elsewhere in that span mentioning
|
|
the composite marked the anchor as installing Rust, and a job that only
|
|
aliased it then passed `validate_rust_jobs_reach_the_composite` while
|
|
installing nothing. That is the same alias-fooled bypass this module's
|
|
docstring warns about, so it gets the same treatment as everything else
|
|
here — the check reads executable steps, never text that merely looks
|
|
like one.
|
|
"""
|
|
anchors: set[str] = set()
|
|
lines = text.splitlines()
|
|
for index, line in enumerate(lines):
|
|
match = ANCHOR_DEF_LINE.match(line)
|
|
if not match:
|
|
continue
|
|
indent = len(line) - len(line.rstrip("\n").lstrip())
|
|
for follower in lines[index + 1 :]:
|
|
if not follower.strip():
|
|
continue
|
|
# First non-blank line at or left of the anchor's own marker ends
|
|
# its node — that is a sibling or a parent, not its content.
|
|
if len(follower) - len(follower.lstrip()) <= indent:
|
|
break
|
|
if SETUP_RUST_USES in follower.split("#")[0]:
|
|
anchors.add(match.group("name"))
|
|
break
|
|
return anchors
|
|
|
|
|
|
def _job_blocks(text: str) -> list[tuple[str, str]]:
|
|
"""Every job in the file, bounded to the `jobs:` mapping.
|
|
|
|
Slicing from the first heading blindly truncated the preamble at the
|
|
first `on:` trigger and made the workflow-level checks dead code on every
|
|
real workflow, so the `jobs:` offset is load-bearing here.
|
|
"""
|
|
jobs_key = JOBS_KEY.search(text)
|
|
return job_blocks(text, jobs_key.start() if jobs_key else 0)
|
|
|
|
|
|
def _reaches_composite(block: str, anchors: set[str]) -> bool:
|
|
return SETUP_RUST_USES in block or any(f"*{a}" in block for a in anchors)
|
|
|
|
|
|
# A cargo/rustc/rustup command actually being invoked -- not `Cargo.toml` in a
|
|
# `paths:` filter, not `cargo` inside a URL or a comment. Bounded on both sides
|
|
# by non-path, non-word characters so `target/cargo-timings` and
|
|
# `scripts/cargo-foo.sh` do not count as running the compiler.
|
|
CARGO_INVOCATION = re.compile(r"(?<![\w./-])(?:cargo|rustc|rustup)(?![\w./-])")
|
|
# The hermetic runners need a toolchain without naming one:
|
|
# run-hermetic-test-process.sh probes `rustc --print sysroot` to build the
|
|
# child PATH and exits 1 if it cannot resolve one. A lane that invokes them
|
|
# therefore needs Rust exactly as much as a literal `cargo` line does, but
|
|
# CARGO_INVOCATION cannot see it -- the workflow only mentions the script.
|
|
# webui-v2-test-lanes was the one lane in this state: it compiles nothing, so
|
|
# nobody noticed it needed rustc, and rustup installed the pinned toolchain
|
|
# lazily mid-test, once per shard, racing its own component downloads.
|
|
NEEDS_TOOLCHAIN_SCRIPT = re.compile(r"run-hermetic-(?:deterministic-suite|test-process)\.sh")
|
|
|
|
|
|
def validate_rust_jobs_reach_the_composite(workflows: dict[str, str]) -> list[str]:
|
|
"""Any job that runs cargo must install Rust through the composite.
|
|
|
|
The release-lane check below is the same rule written for one file. It
|
|
was added after a workflow lost its Rust install entirely and every
|
|
absence-only guard called that clean -- but it only ever protected
|
|
`ironclaw-release.yml`. Deleting the composite step from any other
|
|
workflow reproduced the identical failure with the suite still green,
|
|
because "no dtolnay, no bootstrap, no shadowing RUSTFLAGS" is all
|
|
trivially true of a job that installs nothing at all.
|
|
|
|
Scoped to jobs that actually invoke the compiler, so a docs or frontend
|
|
job needs no exemption. All 31 cargo-running jobs in the tree satisfy
|
|
this today, which is why it ships with no allowlist: an entry here would
|
|
mean a lane building Rust on an unpinned toolchain.
|
|
"""
|
|
|
|
errors: list[str] = []
|
|
for path, text in workflows.items():
|
|
anchors = _composite_anchors(text)
|
|
for name, block in _job_blocks(text):
|
|
code = "\n".join(line.split("#")[0] for line in block.splitlines())
|
|
if not (
|
|
CARGO_INVOCATION.search(code) or NEEDS_TOOLCHAIN_SCRIPT.search(code)
|
|
):
|
|
continue
|
|
if _reaches_composite(block, anchors):
|
|
continue
|
|
errors.append(
|
|
f"{path}: job {name!r} needs a Rust toolchain but never reaches "
|
|
f"`{SETUP_RUST_USES}`. Either it builds on whatever toolchain "
|
|
"the runner image ships (unpinned, no mold), or rustup installs "
|
|
"the pin lazily on first use inside the repo -- mid-lane, once "
|
|
"per shard, racing its own component downloads. Install Rust "
|
|
"through the composite so it happens once, up front."
|
|
)
|
|
return errors
|
|
|
|
|
|
RELEASE_WORKFLOW = ".github/workflows/ironclaw-release.yml"
|
|
DIST_BUILD_SETUP = ".github/dist-build-setup.yml"
|
|
# cargo-dist's container build job — the only job in the release workflow
|
|
# that installs Rust, and the one the contract below actually guards.
|
|
RELEASE_BUILD_JOB = "build-local-artifacts"
|
|
|
|
|
|
# The condition cargo-dist's container build job carries on its Rust install,
|
|
# in both the fragment and the generated workflow. Pinned, not merely tolerated:
|
|
# the contract used to assert the step's TEXT existed and said nothing about
|
|
# when it runs, so `if:` could be narrowed, widened, or dropped silently. The
|
|
# value itself is deliberate -- container images ship without cargo, hosted
|
|
# runners resolve rust-toolchain.toml themselves -- and it matches the
|
|
# pre-composite step exactly, so release behaviour is unchanged by this PR.
|
|
RELEASE_STEP_CONDITION = "if: ${{ matrix.container }}"
|
|
|
|
|
|
def _composite_step_condition(text: str) -> str | None:
|
|
"""The `if:` guarding the composite step, or None if the step is unguarded.
|
|
|
|
Scans the step's WHOLE body, not just the lines above `uses:`. YAML mapping
|
|
keys are unordered, so `uses:` may legally precede `if:`; stopping at the
|
|
`uses:` line reported such a step as unconditional and would have rejected
|
|
a correct release workflow. The step is bounded by its own `- ` marker and
|
|
the next line at or left of that marker.
|
|
"""
|
|
lines = text.splitlines()
|
|
for index, line in enumerate(lines):
|
|
if SETUP_RUST_USES not in line.split("#")[0]:
|
|
continue
|
|
start = index
|
|
while start > 0 and not lines[start].lstrip().startswith("- "):
|
|
start -= 1
|
|
marker_indent = len(lines[start]) - len(lines[start].lstrip())
|
|
end = len(lines)
|
|
for offset in range(start + 1, len(lines)):
|
|
follower = lines[offset]
|
|
if not follower.strip():
|
|
continue
|
|
if len(follower) - len(follower.lstrip()) <= marker_indent:
|
|
end = offset
|
|
break
|
|
for candidate in lines[start:end]:
|
|
stripped = candidate.split("#")[0].strip().lstrip("- ").strip()
|
|
if stripped.startswith("if:"):
|
|
return stripped
|
|
return None
|
|
return None
|
|
|
|
|
|
def _has_composite_step(text: str) -> bool:
|
|
"""True when some EXECUTABLE line invokes the composite.
|
|
|
|
Comment-stripped per line: a substring search over raw text counted a
|
|
commented-out or merely-mentioned `uses:` as an install.
|
|
"""
|
|
return any(SETUP_RUST_USES in line.split("#")[0] for line in text.splitlines())
|
|
|
|
|
|
def validate_release_workflow_installs_rust(
|
|
workflows: dict[str, str], root: Path = ROOT
|
|
) -> list[str]:
|
|
"""The release lane must actually REACH the composite, not merely lack a bootstrap.
|
|
|
|
Most checks here assert an absence — no dtolnay, no raw bootstrap, no
|
|
shadowing RUSTFLAGS. Absence-only checks called a release workflow with NO
|
|
Rust install whatsoever "clean": removing the old `curl | sh` step without
|
|
adding anything passed the whole suite, and a container build would have
|
|
died on `cargo: command not found`.
|
|
|
|
Scoped to `build-local-artifacts` rather than the file, because the file is
|
|
the wrong unit: nothing in ironclaw-release.yml matches a literal `cargo`
|
|
(cargo-dist shells out to `dist build`), so
|
|
`validate_rust_jobs_reach_the_composite` never covers this workflow and
|
|
this is its only guard. A file-wide substring let that job lose its own
|
|
install while an unrelated job — or a comment — kept the contract green.
|
|
|
|
ironclaw-release.yml is generated by cargo-dist from the fragment at
|
|
.github/dist-build-setup.yml, so the step has to exist in BOTH: the
|
|
fragment so `dist generate` keeps emitting it, and the checked-in workflow
|
|
because that is the file GitHub actually runs.
|
|
"""
|
|
|
|
errors: list[str] = []
|
|
release = workflows.get(RELEASE_WORKFLOW)
|
|
if release is not None:
|
|
jobs = dict(_job_blocks(release))
|
|
block = jobs.get(RELEASE_BUILD_JOB)
|
|
if block is None:
|
|
errors.append(
|
|
f"{RELEASE_WORKFLOW}: no {RELEASE_BUILD_JOB!r} job. cargo-dist "
|
|
"names the container build job; if it was renamed, update "
|
|
"RELEASE_BUILD_JOB so this contract keeps guarding it."
|
|
)
|
|
elif _has_composite_step(block) and _composite_step_condition(
|
|
block
|
|
) != RELEASE_STEP_CONDITION:
|
|
found = _composite_step_condition(block) or "<unconditional>"
|
|
errors.append(
|
|
f"{RELEASE_WORKFLOW}: job {RELEASE_BUILD_JOB!r} guards its "
|
|
f"Rust install with {found!r}, not {RELEASE_STEP_CONDITION!r}. "
|
|
"That condition decides which matrix entries reach the "
|
|
"composite at all; changing it changes which release binaries "
|
|
"are built with the pinned toolchain and mold, so it is a "
|
|
"deliberate edit in both this file and "
|
|
f"{DIST_BUILD_SETUP}, not a silent one."
|
|
)
|
|
elif not _has_composite_step(block):
|
|
errors.append(
|
|
f"{RELEASE_WORKFLOW}: job {RELEASE_BUILD_JOB!r} has no "
|
|
f"`{SETUP_RUST_USES}` step. The container build jobs have no "
|
|
"other Rust install path, so this lane would fail with "
|
|
"'cargo: command not found'. Re-run `dist generate` or "
|
|
f"re-inline the step from {DIST_BUILD_SETUP}."
|
|
)
|
|
try:
|
|
fragment = (root / DIST_BUILD_SETUP).read_text(encoding="utf-8")
|
|
except OSError as error:
|
|
errors.append(f"{DIST_BUILD_SETUP}: could not read fragment: {error}")
|
|
else:
|
|
if _has_composite_step(fragment) and _composite_step_condition(
|
|
fragment
|
|
) != RELEASE_STEP_CONDITION:
|
|
found = _composite_step_condition(fragment) or "<unconditional>"
|
|
errors.append(
|
|
f"{DIST_BUILD_SETUP}: guards its Rust install with {found!r}, "
|
|
f"not {RELEASE_STEP_CONDITION!r} — the fragment and the "
|
|
"generated workflow would disagree the next time cargo-dist "
|
|
"regenerates."
|
|
)
|
|
if not _has_composite_step(fragment):
|
|
errors.append(
|
|
f"{DIST_BUILD_SETUP}: no `{SETUP_RUST_USES}` step. cargo-dist "
|
|
"re-inlines this fragment on regeneration, so dropping it here "
|
|
"silently removes the release lane's Rust install the next time "
|
|
"the workflow is regenerated."
|
|
)
|
|
return errors
|
|
|
|
|
|
# Cargo.toml's `[profile.dev] debug = 0` owns the debug-info policy. Anything
|
|
# else ASSIGNING one of these is a second writer of the same value -- harmless
|
|
# while the values agree, and a silent divergence the day someone bumps one.
|
|
# An assignment only: `run-hermetic-test-process.sh` names the same variables
|
|
# in a passthrough allowlist (a `case` pattern, no `=`), which is how a
|
|
# developer's `CARGO_PROFILE_DEV_DEBUG=2` override survives the hermetic
|
|
# barrier. That entry must keep working, so it must not match here.
|
|
# Both syntaxes, because the value was written in both: shell `KEY=value` in
|
|
# scripts, YAML `KEY: value` in workflow job envs. Matching only `=` made this
|
|
# guard blind to the 14 workflow lines this PR deleted -- the majority of what
|
|
# it exists to keep deleted.
|
|
# The key may be bare, double-quoted, or single-quoted -- all three are valid
|
|
# YAML for the same mapping key, and a quoted one bypassed this guard.
|
|
DEBUG_POLICY_ASSIGNMENT = re.compile(
|
|
r"[\"']?CARGO_PROFILE_[A-Z]+_DEBUG[\"']?\s*[:=]"
|
|
)
|
|
# Where the value could be written. `scripts/` covers the shell/python side;
|
|
# `.github/` covers workflow and composite-action env blocks, which is where
|
|
# five job envs carried it before this change.
|
|
DEBUG_POLICY_SEARCH_ROOTS = ("scripts", ".github")
|
|
DEBUG_POLICY_SUFFIXES = (".sh", ".py", ".yml", ".yaml")
|
|
DEBUG_POLICY_OWNER = "Cargo.toml"
|
|
|
|
|
|
def validate_single_debug_policy_owner(root: Path = ROOT) -> list[str]:
|
|
"""Only Cargo.toml may set the debug-info profile values.
|
|
|
|
The migration deleted these env pairs from five workflow job envs on the
|
|
strength of the profile block owning them, but left the identical `:-0`
|
|
defaults standing in two scripts -- so the change's own claim of a single
|
|
owner was not true of the whole tree. Two audit lanes reported it
|
|
independently.
|
|
|
|
The first version of this guard then repeated the mistake in miniature: it
|
|
scanned only `scripts/**` for `KEY=value`, so it could not see the 14
|
|
workflow lines -- the majority of what it was written to keep deleted. Two
|
|
review lanes reported THAT independently. Scope and syntax now cover both
|
|
places the value was actually written.
|
|
"""
|
|
|
|
errors: list[str] = []
|
|
candidates: list[Path] = []
|
|
for search_root in DEBUG_POLICY_SEARCH_ROOTS:
|
|
candidates.extend(sorted((root / search_root).rglob("*")))
|
|
for path in candidates:
|
|
if not path.is_file() or path.suffix not in DEBUG_POLICY_SUFFIXES:
|
|
continue
|
|
# Test files carry the forbidden string on purpose, as fixtures and
|
|
# as the sabotage input that proves this check fires. Scanning them
|
|
# would make the contract unable to have a regression test at all.
|
|
if path.name.startswith(("test_", "test-")):
|
|
continue
|
|
try:
|
|
text = path.read_text(encoding="utf-8")
|
|
except (OSError, UnicodeDecodeError) as error:
|
|
errors.append(f"{path}: could not read: {error}")
|
|
continue
|
|
for number, line in enumerate(text.splitlines(), start=1):
|
|
if DEBUG_POLICY_ASSIGNMENT.search(line.split("#")[0]):
|
|
errors.append(
|
|
f"{path.relative_to(root)}:{number}: assigns a "
|
|
"CARGO_PROFILE_*_DEBUG value, which "
|
|
f"{DEBUG_POLICY_OWNER}'s `[profile.dev]` block owns. Two "
|
|
"writers of one value diverge the day either is bumped; "
|
|
"delete this and let the profile decide."
|
|
)
|
|
return errors
|
|
|
|
|
|
def validate_toolchain_pin_sync(root: Path = ROOT) -> list[str]:
|
|
"""rust-toolchain.toml and the composite's default must name one version."""
|
|
try:
|
|
file_text = (root / "rust-toolchain.toml").read_text(encoding="utf-8")
|
|
except OSError:
|
|
return ["rust-toolchain.toml: missing (single source of truth for the CI toolchain)"]
|
|
channel_match = re.search(r'^channel = "(\d+\.\d+\.\d+)"$', file_text, re.MULTILINE)
|
|
if channel_match is None:
|
|
return ['rust-toolchain.toml: channel must be an exact stable version ("X.Y.Z")']
|
|
channel = channel_match.group(1)
|
|
try:
|
|
action_text = (root / SETUP_RUST_ACTION).read_text(encoding="utf-8")
|
|
except OSError:
|
|
return [f"{SETUP_RUST_ACTION}: missing"]
|
|
# Scoped to the `toolchain:` input's own entry, not the whole file: a
|
|
# `re.search` over the entire action text would resolve to whichever
|
|
# `default: "..."` happens to appear first, which is only the toolchain
|
|
# input's by accident of every other input's default being empty and
|
|
# sitting after it in the file today.
|
|
# `job_body` bounds a two-space `name:` block, which is exactly the
|
|
# shape of an action.yml `inputs:` entry — no second helper needed.
|
|
toolchain_input = job_body(action_text, "toolchain")
|
|
if toolchain_input is None:
|
|
return [f"{SETUP_RUST_ACTION}: no `toolchain:` input found"]
|
|
default_match = re.search(r'default:\s*"([^"]+)"', toolchain_input)
|
|
if default_match is None or default_match.group(1) != channel:
|
|
found = default_match.group(1) if default_match else "<none>"
|
|
return [
|
|
f"{SETUP_RUST_ACTION}: toolchain input default {found!r} != "
|
|
f"rust-toolchain.toml channel {channel!r}"
|
|
]
|
|
return []
|