Stream: git-wasmtime

Topic: wasmtime / PR #13352 [ci] More CI critical-path length op...


view this post on Zulip Wasmtime GitHub notifications bot (May 13 2026 at 18:19):

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.

view this post on Zulip Wasmtime GitHub notifications bot (May 13 2026 at 18:19):

tschneidereit requested pchickey for a review on PR #13352.

view this post on Zulip Wasmtime GitHub notifications bot (May 13 2026 at 18:19):

tschneidereit requested wasmtime-core-reviewers for a review on PR #13352.

view this post on Zulip Wasmtime GitHub notifications bot (May 13 2026 at 18:19):

tschneidereit requested alexcrichton for a review on PR #13352.

view this post on Zulip Wasmtime GitHub notifications bot (May 13 2026 at 18:19):

tschneidereit requested wasmtime-default-reviewers for a review on PR #13352.

view this post on Zulip Wasmtime GitHub notifications bot (May 13 2026 at 18:28):

tschneidereit updated PR #13352.

view this post on Zulip Wasmtime GitHub notifications bot (May 13 2026 at 20:18):

github-actions[bot] added the label wasmtime:api on PR #13352.

view this post on Zulip Wasmtime GitHub notifications bot (May 14 2026 at 10:45):

tschneidereit updated PR #13352.

view this post on Zulip Wasmtime GitHub notifications bot (May 14 2026 at 11:09):

tschneidereit updated PR #13352.

view this post on Zulip Wasmtime GitHub notifications bot (May 14 2026 at 14:56):

:memo: alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (May 14 2026 at 14:56):

: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.js logic I feel like we're not really getting much bang for our buck by refactoring/shuffling tests.

view this post on Zulip Wasmtime GitHub notifications bot (May 14 2026 at 14:56):

: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

view this post on Zulip Wasmtime GitHub notifications bot (May 14 2026 at 14:56):

: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.

view this post on Zulip Wasmtime GitHub notifications bot (May 15 2026 at 12:22):

:memo: tschneidereit submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (May 15 2026 at 12:22):

: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.)

view this post on Zulip Wasmtime GitHub notifications bot (May 15 2026 at 15:49):

:memo: alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (May 15 2026 at 15:49):

: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 all and cargo test --test wast or 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