Divide test run between multiple travis builds. #39664
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
What this PR does is dividing the testing work between multiple travis threads. It should shorten the push-build-edit loop, since the modified job is the one taking much longer that the others. I'll add some doc about the segmentation method when I see that it works. |
|
Could you elaborate on the motivation for such a PR? It looks like the current cycle time for the full test suite on this builder (on PRs today) is just under an hour, and it looks like the sharding here didn't bring an improvement as all the builders are still taking around an hour? In general this is increasing the number of builders we need which increases stress on infrastructure capacity, so we just need to be sure to do so purposefully |
|
Hum, strange, I thought it would have a bigger effect. From better-backtrace, I had the impression that the tests were taking a long time. |
|
☔ The latest upstream changes (presumably #40135) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I'm going to close this due to inactivity, but if there's solid evidence that this can speed up the build please feel free to resubmit! |
No description provided.