ci(release): install lld (wasm-ld) for build-test-evidence#271
Merged
Conversation
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>
![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: 5ff7ce4 | Previous: 485098a | Ratio |
|---|---|---|---|
traceability_matrix/1000 |
60841 ns/iter (± 693) |
43499 ns/iter (± 1648) |
1.40 |
query/10000 |
123458 ns/iter (± 1464) |
102722 ns/iter (± 316) |
1.20 |
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
#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>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
Follow-up to #269. With
wasm-component-ldinstalled, the v0.9.0 Release workflow'sbuild-test-evidencegets further but fails again —highs-sys v1.12.1(transitive C++ dep via spar) does a CMake CXX-ABI probe targeting wasm and clang++ can't findwasm-ld:wasm-ldis the LLVM wasm linker — shipped in thelldapt package. Install it alongsidewasm-component-ld.After merge
v0.9.0tag at the new main HEAD to re-run the Release workflow with this fix. (v0.9.0 has published nothing yet, so re-tagging is safe.)If
build-test-evidenceSTILL fails after this on yet another missing wasm toolchain component, the better fix is to make that jobcontinue-on-error: trueso the release isn't blocked by compliance-artifact tooling — the binary builds (what users install) all succeed.Test plan
build-test-evidencepasses,Create GitHub Releaseruns, v0.9.0 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