appveyor: Shard more slow MSVC builders #48809
Conversation
appveyor.yml
Outdated
| RUST_CHECK_TARGET: check-aux AUX_ARGS="--exclude src/tools/cargotest --exclude src/tools/cargo" | ||
| RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc | ||
| - MSYS_BITS: 64 | ||
| SCRIPT: python x.py test src/test/run-pass src/tools/cargotest src/tools/cargo |
There was a problem hiding this comment.
Hm, this should probably be up above? The ordering here looks a little odd -- maybe I'm not entirely following though.
There was a problem hiding this comment.
@alexcrichton If we are including run-pass here, the x86_64-pc-windows-msvc job (the 1st job) should have --exclude run-pass.
There was a problem hiding this comment.
Oh oops the run-pass was a mistake here, I'll remove that.
|
r=me pending maybe changing the order to be exclude/include instead of the somewhat odd order that I see right now. |
kennytm
added
the
S-waiting-on-review
Take two more slow builders and split them in two to get them under 2 hrs
alexcrichton
force-pushed
the
shard-msvc-more
branch
from
1b1adfa to
7f465ab
Compare
|
@bors: r=Mark-Simulacrum |
|
📌 Commit 7f465ab has been approved by |
bors
added
S-waiting-on-bors
|
Oh I thought the run-pass move was intended, since there were three 3-hour-timeout due to |
|
Oh ok, we don't have enough builders to split that as well. Let's try this sharding and then see if we need another? |
|
I mean one of the two new check-aux jobs will likely be finished in less than 2 hours (I guess the original one since it only runs pretty tests), and perhaps we could move the run-pass test into that job, without increasing the number of builders. We could decide after the concrete numbers come out. |
|
Oh yeah for sure, I figured we'd see the timings first and evaluate after that. |
|
@bors p=200 |
|
⌛ Testing commit 7f465ab with merge 682da145768f244bcd5db4b05240319954792f1c... |
|
@bors: retry prioritizing rollup with this in it |
|
⌛ Testing commit 7f465ab with merge 0bfb2b3cd1b00272492ab8120820a6ddd4661ad9... |
|
@bors: retry prioritizing rollup with this in it |
|
⌛ Testing commit 7f465ab with merge 97f75fab51b27b2b67b9af570861ae95765a23c2... |
|
@bors: r- this will fail, fill fix this in the rollup |
bors
added
S-waiting-on-author
|
@bors: retry |
bors
added
S-waiting-on-bors
…acrum Remove vestigial CI job msvc-aux. This CI job isn't really doing anything, so it seems prudent to remove it. For some history: * This was introduced in rust-lang#48809 when the msvc job was split in two to keep it under 2 hours (oh the good old days). At the time, this check-aux job did a bunch of things: * tidy * src/test/pretty * src/test/run-pass/pretty * src/test/run-fail/pretty * src/test/run-pass-valgrind/pretty * src/test/run-pass-fulldeps/pretty * src/test/run-fail-fulldeps/pretty * Tidy was removed in rust-lang#60777. * run-pass and run-pass-fulldeps moved to UI in rust-lang#63029 * src/test/pretty removed in rust-lang#58140 * src/test/run-fail moved to UI in rust-lang#71185 * run-fail-fulldeps removed in rust-lang#51285 Over time through attrition, the job was left with one lonely thing: `src/test/run-pass-valgrind/pretty`. And of course, this wasn't actually running the "pretty" tests. The normal `run-pass-valgrind` tests ran, and then when it tried to run in "pretty" mode, all the tests were ignored because compiletest thought nothing had changed (apparently compiletest isn't fingerprinting the mode? Needs more investigation…). `run-pass-valgrind` is already being run as part of `x86_64-msvc-1`, so there's no need to run it here. I've taken the liberty of removing `src/test/run-pass-valgrind/pretty` as a distinct test. I'm guessing from the other PR's that the pretty tests should now live in `src/test/pretty`, and that the team has moved away from doing pretty tests on other parts of the `src/test` tree.
…acrum Remove vestigial CI job msvc-aux. This CI job isn't really doing anything, so it seems prudent to remove it. For some history: * This was introduced in rust-lang#48809 when the msvc job was split in two to keep it under 2 hours (oh the good old days). At the time, this check-aux job did a bunch of things: * tidy * src/test/pretty * src/test/run-pass/pretty * src/test/run-fail/pretty * src/test/run-pass-valgrind/pretty * src/test/run-pass-fulldeps/pretty * src/test/run-fail-fulldeps/pretty * Tidy was removed in rust-lang#60777. * run-pass and run-pass-fulldeps moved to UI in rust-lang#63029 * src/test/pretty removed in rust-lang#58140 * src/test/run-fail moved to UI in rust-lang#71185 * run-fail-fulldeps removed in rust-lang#51285 Over time through attrition, the job was left with one lonely thing: `src/test/run-pass-valgrind/pretty`. And of course, this wasn't actually running the "pretty" tests. The normal `run-pass-valgrind` tests ran, and then when it tried to run in "pretty" mode, all the tests were ignored because compiletest thought nothing had changed (apparently compiletest isn't fingerprinting the mode? Needs more investigation…). `run-pass-valgrind` is already being run as part of `x86_64-msvc-1`, so there's no need to run it here. I've taken the liberty of removing `src/test/run-pass-valgrind/pretty` as a distinct test. I'm guessing from the other PR's that the pretty tests should now live in `src/test/pretty`, and that the team has moved away from doing pretty tests on other parts of the `src/test` tree.
Take two more slow builders and split them in two to get them hopefully to around 2 hrs