ci(release): install wasm-component-ld in build-test-evidence#269
Merged
Conversation
The build-test-evidence job builds spar for wasm32-wasip2 via scripts/build-wasm.sh. Recent Rust nightlies stopped bundling `wasm-component-ld` (the WASI Preview 2 component linker) with the target's tools, so the CMake try-compile in a transitive -sys crate's build script fails with `Executable "wasm-component-ld" doesn't exist!`, which fails build-test-evidence and skips Create GitHub Release — blocking the whole release. Install wasm-component-ld explicitly before the WASM build. Surfaced when the v0.9.0 Release workflow failed on this; v0.8.0 happened to land on a nightly that still bundled the linker. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark 'Rivet Criterion Benchmarks'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.
| Benchmark suite | Current: ea91edf | Previous: 660a5b0 | Ratio |
|---|---|---|---|
store_insert/100 |
85412 ns/iter (± 1979) |
64712 ns/iter (± 272) |
1.32 |
store_insert/1000 |
888338 ns/iter (± 27088) |
691021 ns/iter (± 20651) |
1.29 |
store_lookup/100 |
2169 ns/iter (± 14) |
1510 ns/iter (± 4) |
1.44 |
store_lookup/1000 |
25666 ns/iter (± 90) |
18519 ns/iter (± 479) |
1.39 |
store_lookup/10000 |
353376 ns/iter (± 4827) |
273285 ns/iter (± 8003) |
1.29 |
store_by_type/100 |
95 ns/iter (± 6) |
75 ns/iter (± 1) |
1.27 |
store_by_type/1000 |
95 ns/iter (± 0) |
75 ns/iter (± 0) |
1.27 |
store_by_type/10000 |
95 ns/iter (± 1) |
75 ns/iter (± 1) |
1.27 |
schema_load_and_merge |
1223830 ns/iter (± 33798) |
916366 ns/iter (± 3140) |
1.34 |
link_graph_build/100 |
167836 ns/iter (± 834) |
125502 ns/iter (± 590) |
1.34 |
link_graph_build/1000 |
1927358 ns/iter (± 13563) |
1484186 ns/iter (± 19358) |
1.30 |
validate/100 |
142007 ns/iter (± 4492) |
104408 ns/iter (± 955) |
1.36 |
validate/1000 |
1222383 ns/iter (± 12019) |
946010 ns/iter (± 4777) |
1.29 |
traceability_matrix/100 |
4243 ns/iter (± 27) |
3193 ns/iter (± 8) |
1.33 |
traceability_matrix/1000 |
60028 ns/iter (± 624) |
34612 ns/iter (± 140) |
1.73 |
traceability_matrix/10000 |
797346 ns/iter (± 9843) |
566932 ns/iter (± 6065) |
1.41 |
diff/100 |
60566 ns/iter (± 470) |
43810 ns/iter (± 183) |
1.38 |
diff/1000 |
679849 ns/iter (± 2927) |
487443 ns/iter (± 2726) |
1.39 |
query/100 |
782 ns/iter (± 2) |
570 ns/iter (± 1) |
1.37 |
query/1000 |
7700 ns/iter (± 86) |
4821 ns/iter (± 67) |
1.60 |
query/10000 |
108883 ns/iter (± 3766) |
69315 ns/iter (± 421) |
1.57 |
document_parse/10 |
23687 ns/iter (± 324) |
16677 ns/iter (± 250) |
1.42 |
document_parse/100 |
171056 ns/iter (± 1337) |
115679 ns/iter (± 619) |
1.48 |
document_parse/1000 |
1562777 ns/iter (± 105049) |
1058032 ns/iter (± 19974) |
1.48 |
This comment was automatically generated by workflow using github-action-benchmark.
4 tasks
avrabe
added a commit
that referenced
this pull request
May 12, 2026
#271) Follow-up to #269. With wasm-component-ld now installed, the spar wasm32-wasip2 build gets further but then fails: `highs-sys v1.12.1` (a transitive C++ dependency) runs a CMake CXX-ABI detection probe targeting wasm, and clang++ can't find `wasm-ld`: error: failed to spawn "wasm-ld" clang++: error: linker command failed with exit code 1 `wasm-ld` is the LLVM wasm linker, shipped in the `lld` apt package. Install it alongside wasm-component-ld. v0.8.0 built test-evidence on a runner image / nightly combo that still had both. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4 tasks
avrabe
added a commit
that referenced
this pull request
May 12, 2026
#272) After #269 (wasm-component-ld) and #271 (lld/wasm-ld), the build-test- evidence job still fails: the spar wasm32-wasip2 build pulls in highs-sys (a C++ solver), whose CMake CXX-ABI probe needs a full WASI C/C++ SDK — wasm-ld can't find crt1.o, -lc, -lc++, -lc++abi, or libclang_rt.builtins-wasm32.a. The runner image no longer ships a wasi sysroot, and wiring in wasi-sdk is a bigger lift. The test-evidence bundle is a compliance artifact, not a user-facing binary. Mark the job continue-on-error so a failure doesn't skip Create GitHub Release — the release ships 8/9 assets (all binaries + vsix + compliance report + SHA256SUMS, minus rivet-vX.Y.Z-test-evidence.tar.gz). Restoring it properly (install wasi-sdk, set WASI_SDK_PATH) is tracked separately. Surfaced blocking the v0.9.0 release. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
avrabe
added a commit
that referenced
this pull request
May 15, 2026
…-error Follow-up to #269/#271/#272. The spar wasm32-wasip2 build pulls in highs-sys (a C++ solver); building C/C++ for that target needs a full WASI toolchain — a sysroot with libc/libc++/libc++abi plus libclang_rt.builtins-wasm32.a, and a wasm linker. The runner image no longer ships any of it, so even with `lld` (wasm-ld) and wasm-component-ld installed, wasm-ld errored on `crt1.o` / `-lc` / `-lc++`. #272 made the job continue-on-error so the release wasn't blocked (v0.9.0 shipped 8/9 assets, missing only test-evidence.tar.gz). This installs wasi-sdk 25.0 to /opt/wasi-sdk, puts its bin/ on PATH (so wasm-component-ld finds wasm-ld and the cc/cmake build scripts pick up the right clang), and pins CC_/CXX_/AR_wasm32_wasip2 + the wasip2 sysroot via CFLAGS_/CXXFLAGS_wasm32_wasip2 — so both the CMake CXX-ABI probe and the highs-sys compile resolve their headers/libs. `lld` stays as a belt-and-braces wasm-ld source. Drops `continue-on-error` — if test-evidence breaks again it should block the release until fixed. Not verified locally (spar isn't checked out here); the wasip2 sysroot flags or the wasi-sdk version may need a tweak after the first CI run. Alternative for a hermetic toolchain (out of scope here): migrate the spar-wasm build to Bazel rules_wasm_component — a change in the spar repo. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
avrabe
added a commit
that referenced
this pull request
May 15, 2026
…-error (#274) Follow-up to #269/#271/#272. The spar wasm32-wasip2 build pulls in highs-sys (a C++ solver); building C/C++ for that target needs a full WASI toolchain — a sysroot with libc/libc++/libc++abi plus libclang_rt.builtins-wasm32.a, and a wasm linker. The runner image no longer ships any of it, so even with `lld` (wasm-ld) and wasm-component-ld installed, wasm-ld errored on `crt1.o` / `-lc` / `-lc++`. #272 made the job continue-on-error so the release wasn't blocked (v0.9.0 shipped 8/9 assets, missing only test-evidence.tar.gz). This installs wasi-sdk 25.0 to /opt/wasi-sdk, puts its bin/ on PATH (so wasm-component-ld finds wasm-ld and the cc/cmake build scripts pick up the right clang), and pins CC_/CXX_/AR_wasm32_wasip2 + the wasip2 sysroot via CFLAGS_/CXXFLAGS_wasm32_wasip2 — so both the CMake CXX-ABI probe and the highs-sys compile resolve their headers/libs. `lld` stays as a belt-and-braces wasm-ld source. Drops `continue-on-error` — if test-evidence breaks again it should block the release until fixed. Not verified locally (spar isn't checked out here); the wasip2 sysroot flags or the wasi-sdk version may need a tweak after the first CI run. Alternative for a hermetic toolchain (out of scope here): migrate the spar-wasm build to Bazel rules_wasm_component — a change in the spar repo. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Summary
The v0.9.0 Release workflow failed:
build-test-evidenceerrored withclang++: error: unable to execute command: Executable "wasm-component-ld" doesn't exist!during the sparwasm32-wasip2build, which skippedCreate GitHub Release(it's in that job'sneeds:), blocking the entire release.wasm-component-ldis the WASI Preview 2 component linker. Recent Rust nightlies have stopped bundling it with thewasm32-wasip2target's tools, sodtolnay/rust-toolchain@nightly+targets: wasm32-wasip2no longer provides it. v0.8.0 happened to land on a nightly that still bundled it.Fix:
cargo install --locked wasm-component-ldbefore the WASM build step.After merge
v0.9.0tag at the new main HEAD so the Release workflow re-runs with this fix (the v0.9.0 tag published nothing, so re-tagging is safe).Test plan
build-test-evidencepasses,Create GitHub Releaseruns, v0.9.0 release page gets all 9 assetsrelease-npm.ymlauto-fires viaworkflow_run(validates ci(release-npm): switch to workflow_run trigger so npm publish auto-fires #261)npm view @pulseengine/rivet version→ 0.9.0🤖 Generated with Claude Code