Uh oh!
There was an error while loading. Please reload this page.
Add a disabled builder for aarch64 emulated tests - #43226
Conversation
rust-highfive
commented
Jul 14, 2017
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
There was a problem hiding this comment.
An alternate to avoid unbound variable issues: "${TRAVIS:-}${APPVEYOR:-}", though it's possible using $CI would be cleaner.
There was a problem hiding this comment.
tidy check (x86_64-unknown-linux-gnu)
[00:03:20] tidy error: /checkout/src/tools/remote-test-client/src/main.rs:157: line longer than 100 chars
[00:03:20] tidy error: /checkout/src/tools/remote-test-client/src/main.rs:169: line longer than 100 chars
[00:03:21] some tidy checks failed
There was a problem hiding this comment.
As far as I can see, the $CI environment variable is not exported inside docker (https://github.com/rust-lang/rust/blob/4bd27fc/src/ci/docker/run.sh#L70-L87) so this will disable retries for any docker builds.
That aside, I'm reluctant to give users a different experience to what we work with in CI.
There was a problem hiding this comment.
Just to expand on my reluctance - one reason we do CI is so we know other people can build it correctly. I can imagine myself getting frustrated by an intermittent failure, just to realise that rust uses a magic variable to dodge it.
Is there a particular reason for changing it as part of this PR?
There was a problem hiding this comment.
Oops sorry I meant to respond to this earlier! I changed this here because it's a pretty bad experience when working on the docker files. Every failure turns into a "retry" so if you've got a normal failure in the docker image it just gives it to you 5 times which often makes it hard to find the error.
This seems contentious though so I'll just back it out.
bors
commented
Jul 19, 2017
☔ The latest upstream changes (presumably #43316) made this pull request unmergeable. Please resolve the merge conflicts. |
aturon
commented
Jul 19, 2017
cc @rust-lang/infra, anybody up for giving this an official review? |
0f43c8c to
0282dfeCompareaidanhs
commented
Jul 19, 2017
I'll go through it this weekend (unless someone jumps in first). |
aidanhs
left a comment
There was a problem hiding this comment.
Since this is disabled I don't particularly mind r+ing this mostly as-is, but the CI variable stuff needs tweaking in some way (either passing it down to docker, or removing the retry disabling) or I think we're going to start seeing spurious failures again.
There was a problem hiding this comment.
Looks like we use zImage for armhf, it'd probably be nice if we did the same here just for consistency.
There was a problem hiding this comment.
I would yeah, but the normal build process didn't create that, so we didn't have it to use it :(
There was a problem hiding this comment.
I should mention that I know nothing about kernel build processes, I just found that this particular configuration didn't create a zImage
There was a problem hiding this comment.
This and rcS above are being pulled out of the armhf-gnu folder - maybe a qemu-common folder?
There was a problem hiding this comment.
Just to expand on my reluctance - one reason we do CI is so we know other people can build it correctly. I can imagine myself getting frustrated by an intermittent failure, just to realise that rust uses a magic variable to dodge it.
Is there a particular reason for changing it as part of this PR?
1fe1437 to
eb6f996Comparealexcrichton
commented
Jul 24, 2017
Updated! |
There was a problem hiding this comment.
This needs to use the interner in the new rustbuild, see the ARMHF line above. Looks like it changed underneath you!
aidanhs
commented
Jul 24, 2017
r=me with the interning fix to get the PR build passing and the move of addentropy.c |
This commit adds a disabled builder which will run all tests for the standard library for aarch64 in a QEMU instance. Once we get enough capacity to run this on Travis this can be used to boost our platform coverage of AArch64
alexcrichton
commented
Jul 24, 2017
@bors: r=aidanhs |
bors
commented
Jul 24, 2017
📌 Commit 8ef3f69 has been approved by |
bors
commented
Jul 25, 2017
⌛ Testing commit 8ef3f69 with merge 1399c0d92e42e5510d784e3015e87c3c2eef7481... |
bors
commented
Jul 25, 2017
💔 Test failed - status-travis |
Mark-Simulacrum
commented
Jul 25, 2017
LLVM just stopped building... presumably sccache related? Not sure. cc @alexcrichton @bors retry
|
bors
commented
Jul 25, 2017
⌛ Testing commit 8ef3f69 with merge e0d7d4672073054e89eeebfc2287427305cb6301... |
bors
commented
Jul 25, 2017
💔 Test failed - status-travis |
alexcrichton
commented
Jul 25, 2017
bors
commented
Jul 25, 2017
⌛ Testing commit 8ef3f69 with merge e68b13ae6fab2d475a3d831257d85932867be3fe... |
bors
commented
Jul 25, 2017
💔 Test failed - status-travis |
kennytm
commented
Jul 25, 2017
Same error, should be legit. |
aidanhs
commented
Jul 25, 2017
Third time in a row for that hang while building LLVM, but I can't figure out what's causing it given that virtually nothing has changed about armhf. My best guess is something to do with the docker build not being cached any more so some steps are re-run, but the only one that looks like it could change is the acquisition of @alexcrichton any thoughts? |
alexcrichton
commented
Jul 25, 2017
I have no idea how this PR could be related to that error. I'm running tests locally to try to replicate, I doubt I will be successful. |
alexcrichton
commented
Jul 25, 2017
@bors: retry Continue to be no failures locally, and I can't fathom how this is related to that... |
bors
commented
Jul 26, 2017
Add a disabled builder for aarch64 emulated tests This commit adds a disabled builder which will run all tests for the standard library for aarch64 in a QEMU instance. Once we get enough capacity to run this on Travis this can be used to boost our platform coverage of AArch64
bors
commented
Jul 26, 2017
☀️ Test successful - status-appveyor, status-travis |
This commit adds a disabled builder which will run all tests for the standard
library for aarch64 in a QEMU instance. Once we get enough capacity to run this
on Travis this can be used to boost our platform coverage of AArch64