-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Change Travis CI job order. #43287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Travis CI job order. #43287
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
(In the Travis CI PR build of this commit, 9 minutes and 6 minutes are respectively taken to skip two macOS builds. Both are due to |
@bors: r+ |
📌 Commit d19ae39 has been approved by |
⌛ Testing commit d19ae399d86ab5ba1dd2083f02434c633d7964bc with merge 299836dc82b7f1874ffa0379732a8e54eb70568c... |
💔 Test failed - status-travis |
Failed to download sccache. Spurious. But let's not retry since #43293 will conflict with this anyway. |
☔ The latest upstream changes (presumably #43293) made this pull request unmergeable. Please resolve the merge conflicts. |
Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
d19ae39
to
a7eb87e
Compare
Rebased. @alexcrichton |
Hmm, I'm a bit confused. Looking at the log it didn't even try to download sccache, which is reasonable because it should be cached in the docker image. So what's up with
? |
Right I see, a failed curl in a different build polluted our docker cache until #43293 was made to fix it, and this build was one of the casualties. |
@bors: r+ |
📌 Commit a7eb87e has been approved by |
@bors rollup |
…excrichton Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so pull requests will start testing as immediately after the build is started. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed). (IMO `$SKIP_BUILD` should not even exist: those irrelevant jobs should not start at all, but that would require travis-ci/travis-ci#2778 which has been rejected)
Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of
.travis.yml
.Move the
$ALLOW_PR
image to the top, so pull requests will start testing as immediately after the build is started. Previously the$ALLOW_PR
image starts 6 minutes after the build was scheduled.Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work).
Merged the
install
section of both Linux and macOS to make theenv:
section a bit shorter, and enable change 4 below.Do not download or install anything if
$SKIP_BUILD == true
, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).(IMO
$SKIP_BUILD
should not even exist: those irrelevant jobs should not start at all, but that would require travis-ci/travis-ci#2778 which has been rejected)