Skip to content

ci(release): make build-test-evidence non-blocking#272

Merged
avrabe merged 1 commit into
mainfrom
fix/release-test-evidence-non-blocking
May 12, 2026
Merged

ci(release): make build-test-evidence non-blocking#272
avrabe merged 1 commit into
mainfrom
fix/release-test-evidence-non-blocking

Conversation

@avrabe
Copy link
Copy Markdown
Contributor

@avrabe avrabe commented May 12, 2026

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 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: error: cannot open crt1.o: No such file or directory
wasm-ld: error: unable to find library -lc++ / -lc++abi / -lc
wasm-ld: error: cannot open .../wasip2/libclang_rt.builtins-wasm32.a

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: true on the build-test-evidence job. A failure no longer skips Create GitHub Release; the release ships 8/9 assets (missing only rivet-vX.Y.Z-test-evidence.tar.gz). Restoring it properly is tracked separately.

After merge

  • Delete + re-create v0.9.0 tag at the new main HEAD to re-run the Release workflow.

Test plan

🤖 Generated with Claude Code

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>
Copy link
Copy Markdown

@github-actions github-actions Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ 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.

@avrabe avrabe merged commit 02b9328 into main May 12, 2026
13 of 14 checks passed
@avrabe avrabe deleted the fix/release-test-evidence-non-blocking branch May 12, 2026 16:01
@codecov
Copy link
Copy Markdown

codecov Bot commented May 12, 2026

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>
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant