Wasmtime GitHub notifications bot (Apr 17 2024 at 16:46): Wasmtime GitHub notifications bot (Apr 17 2024 at 16:46):elliottt opened PR #8396 from elliottt:trevor/nextest to bytecodealliance:main:
cargo-nextesthas a better strategy for running tests in parallel, which should allow us to improve CI time by not waiting on long-pole tests like cranelift-tools::filetests.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Apr 17 2024 at 16:47):elliottt updated PR #8396.
Wasmtime GitHub notifications bot (Apr 17 2024 at 16:50):elliottt updated PR #8396.
Wasmtime GitHub notifications bot (Apr 17 2024 at 17:08):elliottt updated PR #8396.
Wasmtime GitHub notifications bot (Apr 17 2024 at 17:54):elliottt updated PR #8396.
Wasmtime GitHub notifications bot (Apr 17 2024 at 18:16):elliottt updated PR #8396.
Wasmtime GitHub notifications bot (Apr 17 2024 at 18:20):elliottt edited PR #8396:
cargo-nextesthas a better strategy for running tests in parallel, which should allow us to improve CI time by not waiting on long-pole tests like cranelift-tools::filetests.This PR does continue testing
wasi-commonwithcargo test, asnextestdoesn't allocate a pty to each test (https://github.com/nextest-rs/nextest/issues/1357). Without this change, those tests reliably fail when attempting to poll stdin/stdout.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Apr 17 2024 at 18:50):elliottt updated PR #8396.
Wasmtime GitHub notifications bot (Apr 17 2024 at 19:16):elliottt updated PR #8396.
Wasmtime GitHub notifications bot (Apr 17 2024 at 20:45):alexcrichton commented on PR #8396:
Comparing this with another run sampled historically I don't think there's any speedup? That matches my gut on this given the low core count of actions runners and how all our tests are internally parallel too.
Wasmtime GitHub notifications bot (Apr 17 2024 at 20:47):elliottt updated PR #8396.
Wasmtime GitHub notifications bot (Apr 17 2024 at 20:51):elliottt commented on PR #8396:
Comparing this with another run sampled historically I don't think there's any speedup? That matches my gut on this given the low core count of actions runners and how all our tests are internally parallel too.
I'm seeing 15 vs 18 minutes for the Linux x64 run, and that's with the non-cached build of
cargo-nextest.
Wasmtime GitHub notifications bot (Apr 17 2024 at 20:53):elliottt edited a comment on PR #8396:
Comparing this with another run sampled historically I don't think there's any speedup? That matches my gut on this given the low core count of actions runners and how all our tests are internally parallel too.
I'm seeing 15 vs 18 minutes for the Linux x64 run, though that's with the cached build of
cargo-nextest.
Wasmtime GitHub notifications bot (Apr 17 2024 at 20:56):elliottt commented on PR #8396:
Comparing this with another run sampled historically I don't think there's any speedup? That matches my gut on this given the low core count of actions runners and how all our tests are internally parallel too.
I'm seeing 15 vs 18 minutes for the Linux x64 run, though that's with the cached build of
cargo-nextest.Never mind, @alexcrichton pointed out that this is due to not running the lldb tests on branches :)
Wasmtime GitHub notifications bot (Apr 17 2024 at 21:03):elliottt updated PR #8396.
Wasmtime GitHub notifications bot (Apr 17 2024 at 21:15):elliottt closed without merge PR #8396.
Wasmtime GitHub notifications bot (Apr 17 2024 at 21:15):elliottt commented on PR #8396:
Given that this isn't really speeding up testing, I don't think this is worth pursuing. If we decide to start partitioning tests onto different runners in the future it would be worth picking this back up, but without that the benefit just isn't there.
Wasmtime GitHub notifications bot (Apr 17 2024 at 21:46):elliottt reopened PR #8396.
Wasmtime GitHub notifications bot (Apr 17 2024 at 21:53):elliottt updated PR #8396.
Last updated: Dec 23 2024 at 12:05 UTC