ci(freebsd): restore wasm-cross E2E parity on the x86_64 FreeBSD lanes - #2871
Open
gertybotbot wants to merge 2 commits into
Open
ci(freebsd): restore wasm-cross E2E parity on the x86_64 FreeBSD lanes#2871gertybotbot wants to merge 2 commits into
gertybotbot wants to merge 2 commits into
Conversation
The FreeBSD jobs installed the `rust` pkg, which is not rustup-managed and therefore ignores rust-toolchain.toml. That file already pins the channel and lists wasm32-wasip1 under `targets`, so every rustup platform provisions the WASI target automatically -- FreeBSD was the sole outlier, and the eval_wasm_* / wasi_run_e2e E2E tests were filtered out of the run to work around it. Install rustup instead of the pkg toolchain on the two x86_64 FreeBSD lanes (release-gate.yml and freebsd.yml) and drop the `-E` exclusion, so those lanes now build the WASI runner from source and execute it under the pkg wasmtime like the other platforms. The run asserts wasm32-wasip1 is actually installed before relying on it, so a provisioning regression fails loudly rather than silently reverting to reduced coverage. Upstream publishes rustup-init and all pinned components (rust, clippy, rustfmt, rust-std wasm32-wasip1) for x86_64-unknown-freebsd, verified against the 1.96.0 channel manifest. The aarch64 gate keeps the exclusion: upstream Rust ships no aarch64-unknown-freebsd host at all -- no rustup-init and no `rust` entry in the channel manifest -- so this fix cannot apply there at any version. Its comment now records that as permanent rather than pending hew-lang#1960. Verified: scripts/check-preflight-ci-parity.sh and scripts/check-gate-reachability.py both exit 0 (A3d drops 8 -> 6 filtered nextest runs, all still compensated). Closes hew-lang#1960
The oracle pinned ONE canonical form across all FreeBSD jobs: a single nextest command carrying the wasm-cross `-E` exclusion, and a tool set containing the `rust` pkg. The preceding commit makes the x86_64 lanes legitimately differ, so the oracle had to learn the split rather than be loosened. Adds a RUSTUP_JOBS set (build-and-test, gate-freebsd-x86_64) and makes the two existing per-job helpers architecture-aware: - `_expected_nextest_command()` returns the unfiltered command for rustup lanes and keeps the `-E` filtered command for aarch64. - `_expected_pkg_phases()` swaps `rust` for `curl` on rustup lanes. - rustup provisioning (rustup-init, `rustup show active-toolchain`, and the `rustup target list --installed | grep -qx wasm32-wasip1` probe) is now REQUIRED on those lanes and covered by the comment-out mutation test. The mutation tests that hard-coded the old constants now derive the install line and nextest command from the job under test, so they keep biting per job instead of silently passing. Verified the oracle still rejects, each confirmed by a non-zero exit: - removing the wasm32-wasip1 target probe from the x86_64 gate - re-adding the `-E` exclusion to the x86_64 gate (a coverage regression) - removing the `-E` exclusion from the aarch64 gate (unsupported target) Full set green: freebsd-workflow-contract-check 23/23, test-release-workflow-contract 20/20, check-preflight-ci-parity.sh, check-gate-reachability.py.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1960.
What was wrong
The FreeBSD jobs install the
rustpkg, which is not rustup-managed and therefore ignoresrust-toolchain.toml. That file already pins the channel and listswasm32-wasip1undertargets, so every rustup platform provisions the WASI target automatically. FreeBSD was the sole outlier, so theeval_wasm_*/wasi_run_e2eE2E tests were filtered out with an-Eexpression to work around it.Worth noting: the issue's suggested restore path was "install a rustup toolchain, then
rustup target add wasm32-wasip1". Therustup target addstep turns out to be unnecessary —targetsinrust-toolchain.tomlcovers it.What this does
On the two x86_64 FreeBSD lanes (
release-gate.ymlandfreebsd.yml— the CI workflow had the same exclusion, so fixing only the gate would have left the issue half-done):rustpkg (curladded,rustdropped)-Eexclusion so the lanes build the WASI runner from source and run it under the pkgwasmtime, like the other platformsrustup target list --installed | grep -qx wasm32-wasip1before the suite relies on it, so a provisioning regression fails loudly instead of silently reverting to reduced coverageLLVM_SYS_221_PREFIXstill points at the pkgllvm22; only the Rust toolchain source changes.Availability, verified against the pinned channel
rust-toolchain.tomlpins1.96.0. Againstchannel-rust-1.96.0.toml, all ofrust,clippy-preview,rustfmt-previewforx86_64-unknown-freebsdandrust-stdforwasm32-wasip1areavailable = true, andrustup-initforx86_64-unknown-freebsdreturns HTTP 200.The aarch64 lane keeps the exclusion — permanently
Upstream Rust ships no
aarch64-unknown-freebsdhost at all:rustup-init404s and there is norustentry in the channel manifest. This fix cannot apply there at any version, so that lane keeps the filter and its comment now records the reason as permanent rather than pending #1960. The issue did not distinguish the two architectures; that asymmetry is the main finding here.Verification
scripts/check-preflight-ci-parity.sh→ exit 0 (32/32 checks, 28/28 steps, 5/5 lane→gate)scripts/check-gate-reachability.py→ exit 0; A3d drops 8 → 6 filtered nextest runs, all still compensatedCI on this PR does not exercise the FreeBSD release-gate lane, so the FreeBSD legs are proven by the release-gate workflow rather than here.