tschneidereit opened PR #13352 from tschneidereit:ci-opts-full to bytecodealliance:main:
These ones are a bit more speculative than the ones in #13340, and are meant to shorten the wall-clock duration of full CI runs, not just PR runs.
More speculative because at least the last commit, parallelizing release builds of the wasmtime CLI and libwasmtime, comes at the cost of a fairly high degree of duplicate work per job, so we'll have to assess whether the reduction in wall-clock time is worth it.
Stacked on top of #13340.
tschneidereit requested pchickey for a review on PR #13352.
tschneidereit requested wasmtime-core-reviewers for a review on PR #13352.
tschneidereit requested alexcrichton for a review on PR #13352.
tschneidereit requested wasmtime-default-reviewers for a review on PR #13352.
tschneidereit updated PR #13352.
github-actions[bot] added the label wasmtime:api on PR #13352.
tschneidereit updated PR #13352.
tschneidereit updated PR #13352.
:memo: alexcrichton submitted PR review.
:speech_balloon: alexcrichton created PR review comment:
While I've no doubt this works, personally I dread this sort of CI configuration of "giant wad of script/shell/etc in yml" as it's generally quite difficult to reproduce and/or onerous to work with locally. Especially if this is duplciated with the (already quite large)
build-text-matrix.jslogic I feel like we're not really getting much bang for our buck by refactoring/shuffling tests.
:speech_balloon: alexcrichton created PR review comment:
I'll also point out that the increase in complexity of all the shell scripts here is pretty significant. I already loathe shell scripts and I'm always wary of making them even more complicated. Basically my personal complexity threshold for a shell script is quite low and I feel that the additions here definitely push it over the edge
:speech_balloon: alexcrichton created PR review comment:
Personally I'm wary of continuing to fork jobs as I feel like we're already more-or-less at the limit, even at 500 concurrency. A job already spawns 100+ jobs for all the platforms/checks/etc and doubling all release jobs will probably push this closer to 200. That can be a pretty big problem for things like security advisories where we do multiple CI runs at once -- that already takes hours -- and continuing to fork things will push that time even higher.
Personally I feel like 20-30m is pretty reasonable for CI for Wasmtime at this time. Shaving a few minutes off here and there by drastically increasing total CPU time I feel isn't worth it myself.
:memo: tschneidereit submitted PR review.
:speech_balloon: tschneidereit created PR review comment:
as mentioned in the PR description, I wasn't at all sure if these changes are worth it, yeah. I personally think that the complexity is manageable, but certainly agree that this comes at a pretty steep cost. And it seems like the "quick" check improvements are more important anyway. I'll drop the changes here except for the ones that aren't introducing tradeoffs (which probably means all but the first commit, which eliminates needless work.)
:memo: alexcrichton submitted PR review.
:speech_balloon: alexcrichton created PR review comment:
If the goal is to primarily get CI to complete faster I think it'd be reasonable to specialize entirely on that, for example having just two jobs that runs
cargo test --test allandcargo test --test wastor something like that. That way we wouldn't have to worry about losing testing (other builders wouldn't be affected) and nor would be have to worry about the long-poll (both just run a single test suite). We could then turn down some testing automatically done in CI from the other matrix entries (e.g. skip the wasmtime job by default) or something like that
Last updated: Jun 01 2026 at 09:49 UTC