fitzgen requested alexcrichton for a review on PR #8612.
fitzgen requested wasmtime-default-reviewers for a review on PR #8612.
fitzgen opened PR #8612 from fitzgen:ci-shard-tests
to bytecodealliance:main
:
<!--
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
-->
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen commented on PR #8612:
Successful default PR run in ~8 minutes now: https://github.com/bytecodealliance/wasmtime/actions/runs/9073195225
Going to do a full run in a second.
fitzgen updated PR #8612.
fitzgen commented on PR #8612:
Unfortunately, it looks like
cargo nextest
's CI partitioning isn't exposed/supported bycargo miri
.
fitzgen updated PR #8612.
fitzgen requested wasmtime-compiler-reviewers for a review on PR #8612.
fitzgen requested abrown for a review on PR #8612.
fitzgen requested wasmtime-core-reviewers for a review on PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen commented on PR #8612:
Successful full test run in 14 minutes: https://github.com/bytecodealliance/wasmtime/actions/runs/9075621159?pr=8612
github-actions[bot] commented on PR #8612:
Subscribe to Label Action
cc @cfallin, @fitzgen
<details>
This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "cranelift:area:machinst", "cranelift:area:x64", "isle", "wasmtime:api"Thus the following users have been cc'd because of the following labels:
- cfallin: isle
- fitzgen: isle
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
alexcrichton commented on PR #8612:
Thanks for working on this! I'm personally a bit worried about the complexity creep here. Our CI is already pretty nontrivial and adding this into the mix I feel like takes it up to another level of complexity which makes it harder for future contributors/modifications. I can't argue with the results of course, but the merge queue currently reports that the average time-to-merge is 19 minutes so this whould shave 5 minutes off merge time. Given that we generally have an empty queue and we don't have many time-pressured PRs I'm not sure whether the 25% reduction in CI will be worth the complexity increase here.
I'll admit though I'm pretty biased as I'm still sort of used to the 3-hour-cycle-time from rust-lang/rust so my perception of what's appropriate for CI is likely pretty skewed. I'm curious how others feel as well as to the tradeoff of CI complexity here vs the time reduction.
abrown submitted PR review:
I think this is great though I didn't take enough time to understand the sharding in
ci/build-test-matrix.js
; walking through a short example in the doc comment might help because it all looks a bit complex. But overall speeding up CI is great; it looks like this would bring it down from 20+ minutes to ~14 minutes. @alexcrichton, any other comments?
fitzgen commented on PR #8612:
Yeah I can definitely add more docs/comments if we want to continue down this route.
I think the default PR check time dropping from ~15 minutes to ~8 minutes is the real benefit here; more so than the 20 to 14 for full CI, at least IMO.
fitzgen submitted PR review.
fitzgen created PR review comment:
I think this job is worth splitting out regardless if we want the rest of this PR. This is an extra 4-5 minutes at the end of a full
ci/run-tests.sh
onmain
.
alexcrichton submitted PR review:
Ok I've added some thoughts below but if you could add some more documentation specifically to sharding I think that'd be good.
I'll also point out that this is quite a lot of sharding, more than I've ever seen done before on github actions, so while I have no reason to think things will go wrong there's always the possibility we uncover something strange in the future. Most projects I don't think approach anywhere near this concurrency. The micro_checks job is also very heavily sharded where commands that might take ~5 seconds now take ~1 minute due to the overhead of a runner, downloading rustc, downloading deps, etc. That's not going to break the bank with our concurrency limit though so I don't have any reason to not do this.
alexcrichton submitted PR review:
Ok I've added some thoughts below but if you could add some more documentation specifically to sharding I think that'd be good.
I'll also point out that this is quite a lot of sharding, more than I've ever seen done before on github actions, so while I have no reason to think things will go wrong there's always the possibility we uncover something strange in the future. Most projects I don't think approach anywhere near this concurrency. The micro_checks job is also very heavily sharded where commands that might take ~5 seconds now take ~1 minute due to the overhead of a runner, downloading rustc, downloading deps, etc. That's not going to break the bank with our concurrency limit though so I don't have any reason to not do this.
alexcrichton created PR review comment:
I think it might be best to simplify this and replace it with
--all-features
. Most of the above features are on-by-default but it's also not an exhaustive list of off-by-default features that should be tested for crates. For examplewasmtime-environ
should have thecompile
feature enabled when testing, which it is today due to feature unioning but if it's split to its own job then it's probably best to slap--all-features
and call it a day here.
alexcrichton created PR review comment:
Technically-speaking rather than using a regex for this it's probably best to build a map based on the output of
cargo metadata
and lookup things bad on id to project out the package name from the package metadata in the json blob. (probably more robust than regex-matching)
alexcrichton created PR review comment:
AFAIK the
extra_features
bits here are exclusively for wasi-nn and ONNX stuff so I feel like we're carrying quite a lot of stuff in CI configuration just for that. At that point it might be best to just split out that build/test entirely into its own job? That'd help remove all the special casing aroundextra_features
here
alexcrichton created PR review comment:
This I think can be removed as it's only used by the one below.
alexcrichton created PR review comment:
This logic may not be quite so true any more given the more matrix entries we have, could the
item.isa
item be required here to basically only run the isa-based builders on runtest modifications? (e.g. not msrv)
fitzgen commented on PR #8612:
I'll also point out that this is quite a lot of sharding, more than I've ever seen done before on github actions, so while I have no reason to think things will go wrong there's always the possibility we uncover something strange in the future. Most projects I don't think approach anywhere near this concurrency. The micro_checks job is also very heavily sharded where commands that might take ~5 seconds now take ~1 minute due to the overhead of a runner, downloading rustc, downloading deps, etc. That's not going to break the bank with our concurrency limit though so I don't have any reason to not do this.
Yeah I actually wanted to group that CI job into buckets of ~10 checks each or something but I couldn't figure out an easy way to do that ¯\\\_(ツ)\_/¯
fitzgen updated PR #8612.
fitzgen commented on PR #8612:
Okay I think I figured out how to avoid having a billion
check
jobs
fitzgen requested alexcrichton for a review on PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen requested wasmtime-fuzz-reviewers for a review on PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
fitzgen updated PR #8612.
github-actions[bot] commented on PR #8612:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "fuzzing"Thus the following users have been cc'd because of the following labels:
- fitzgen: fuzzing
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
alexcrichton submitted PR review.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Do you think it's worth decreasing the size of the matrix here? This feels pretty intensive for something that isn't that platform-specific per-se. Maybe only doing linux/windows here or just linux?
fitzgen submitted PR review.
fitzgen created PR review comment:
I was just copying what existed before via tagging along on the main tests, but I'm fine cutting this down to linux and windows.
fitzgen updated PR #8612.
fitzgen has enabled auto merge for PR #8612.
fitzgen merged PR #8612.
Last updated: Nov 22 2024 at 16:03 UTC