ci(release): make build-test-evidence non-blocking#272
Merged
Conversation
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>
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: df7779c | Previous: 56f5d0f | Ratio |
|---|---|---|---|
link_graph_build/10000 |
32720422 ns/iter (± 2134899) |
25363394 ns/iter (± 1506207) |
1.29 |
query/10000 |
159448 ns/iter (± 1520) |
121634 ns/iter (± 858) |
1.31 |
This comment was automatically generated by workflow using github-action-benchmark.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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 was referenced May 16, 2026
avrabe
added a commit
that referenced
this pull request
May 16, 2026
…) — round 2 (#293) (#294) v0.10.0 manual republish forensics: The release workflow on tag v0.10.0 (run 25966236046) built all five cross-platform binaries, the VSIX, the compliance report, the baseline snapshot, and ran docs-check successfully. The "Create GitHub Release" job was skipped because it `needs: build-test-evidence`, and that job failed on the spar -> highs-sys WASI cross-compile (CMake Threads::Threads target not available in the wasi-sdk 25.0 sysroot). The release was published manually from the workflow artifacts. To prevent this hand-republish on every future tag push: - `build-test-evidence`: `continue-on-error: true`. The job still runs and uploads its artifact when it succeeds (desirable add-on), but a failure no longer marks the run as failed. - `create-release.needs`: drop `build-test-evidence`. The Collect assets step uses a permissive `find` and tolerates the missing tarball. History: #272 originally introduced the continue-on-error; #274 reverted it with the wasi-sdk integration that we expected to handle highs-sys. v0.10.0 proved that's still not enough. Tracking the upstream fix in #293 — once that's resolved, this commit can be reverted. Refs: #293
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
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 has been blocked for several iterations by
build-test-evidence. After #269 (wasm-component-ld) and #271 (lld/wasm-ld), it still fails — the sparwasm32-wasip2build pulls inhighs-sys(a C++ solver), whose CMake CXX-ABI probe needs a full WASI C/C++ SDK:The runner image no longer ships a WASI sysroot, and wiring in
wasi-sdk(download,WASI_SDK_PATH, point clang at the sysroot) is a bigger lift than is worth blocking a release on. The test-evidence bundle is a compliance artifact, not a user-facing binary — all 5 binary archives + vsix + compliance report build fine.Fix:
continue-on-error: trueon thebuild-test-evidencejob. A failure no longer skipsCreate GitHub Release; the release ships 8/9 assets (missing onlyrivet-vX.Y.Z-test-evidence.tar.gz). Restoring it properly is tracked separately.After merge
v0.9.0tag at the new main HEAD to re-run the Release workflow.Test plan
Create GitHub Releaseruns even thoughbuild-test-evidencefails; v0.9.0 page gets 8 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