make travis extreme #27205
make travis extreme #27205
Conversation
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
See https://travis-ci.org/Gankro/rust/builds for experimental runs (contrary to the commit messages, ccache was working on all these builds -- travis is magic). |
| @@ -21,7 +21,8 @@ before_script: | |||
| - ./configure --enable-ccache | |||
| script: | |||
| - make tidy | |||
| - make rustc-stage1 -j4 | |||
| - make -j4 | |||
There was a problem hiding this comment.
Btw, why not just make check -j4?
With 4 jobs check is usually finished even before all, i.e. time(make check -j4) ≈ time(make -j4).
There was a problem hiding this comment.
Running make check in parallel has historically caused... exotic problems. Tests already run in parallel regardless (though test groups won't).
There was a problem hiding this comment.
Yeah make check -j4 should work just fine here
There was a problem hiding this comment.
Ah and to clarify make check in parallel has been fixed recently and I haven't run into any problems with it recently as well (plus this is a good way to test it). Building the unit tests in parallel may have a definite win.
|
We may want to add to have pretty fails short-circuit the build (it seems I was mistaken as to the behaviour in my previous PR) |
|
Just to make sure, but if we updated LLVM (and hence invalidate the ccache), does a build still complete before travis times us out? |
|
Updating doesn't actually invalidate the ccache right? It will still do an incremental rebuild? |
|
Nah but I think you can delete the caches manually from the web interface |
|
If the cache is destroyed, it's about 1:25 - https://travis-ci.org/rust-lang/rust/builds/72036834 I'm currently filing a bug against travis to make sure we can rely on this. |
|
👍 |
|
Tracking at travis-ci/travis-ci#4521 |
Gankra
force-pushed
the
travis-extreme
branch
2 times, most recently
from
346a8a1 to
2191d76
Compare
|
isn't stage2 just for sanity? shouldn't check-stage1 always have the same result as check? |
|
stage2 ensures that plugins have the same ABI as the compiler they're running on. Historically |
|
travis also re-tests PRs that were merged by bors... https://travis-ci.org/rust-lang/rust/builds/72454339 |
|
It still failed the build, though. On Fri, Jul 24, 2015 at 8:49 AM, Oliver Schneider [email protected]
|
|
|
||
| env: | ||
| - CXX=/usr/bin/g++-4.7 | ||
| matrix: |
There was a problem hiding this comment.
this is used in the wrong area, I would suggest removing this.
There was a problem hiding this comment.
Should it just not be nested under env? The documentation seems unclear (I've only ever seen matrix nested under env).
There was a problem hiding this comment.
why not remove this altogether and change script to make tidy check -j4?
There was a problem hiding this comment.
Woah that works?!
Crazy undocumented build systems...
|
any reason not to merge this? |
|
We're waiting to hear back from travis about timeouts. |
|
@bors: r+ |
|
📌 Commit b0acde7 has been approved by |
Only `make -j4` takes ~50 mins `make check` bumps it up to ~1hr 30min Travis seems more than happy to let this happen. Time limits appear to be meaningless. Similar to the previous PR, it's easy to tell how much your PR definitely builds by checking the current logs or just considering how long it's been building for.
|
RIP TRAVIS |
|
Oh, is Travis RIP on rust-lang? We have something special which you might be interested in trying out. If someone could reach out to me via email (josh at travis-ci dot com) I can give some more information. Have a great weekend. |
|
@joshk email sent! |
Only
make -j4takes ~50 minsmake checkbumps it up to ~1hr 30minTravis seems more than happy to let this happen.
Time limits appear to be meaningless.
Similar to the previous PR, it's easy to tell how much your PR definitely builds by checking the current logs or just considering how long it's been building for.