-
Notifications
You must be signed in to change notification settings - Fork 13.4k
ci: Upgrade Travis to Xenial #56958
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
ci: Upgrade Travis to Xenial #56958
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
📌 Commit a63512781432e9725b12d868f3b1943fec255549 has been approved by |
cc @kennytm |
@alexcrichton won’t this increase the GLIBC version, or is the toolchain independent from the ubuntu version used? |
It won't, no, because the travis environment isn't used to build any release artifacts. Those are all done in controlled docker containers |
@bors p=1 |
⌛ Testing commit a63512781432e9725b12d868f3b1943fec255549 with merge 1ba94970bef02d5f268b685c8b7f2b3969d9ca08... |
💔 Test failed - status-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@bors retry 3 hour timeout (expected) |
⌛ Testing commit a63512781432e9725b12d868f3b1943fec255549 with merge 693757dbae269f8473dae87a123c7cf4d7435b36... |
💔 Test failed - status-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@bors retry |
Ok I think this is a cache thrashing issue. Looks like caches indeed are still updated in this PR and are actually reused, but my guess is that the problem is that this PR is using the same cache as the current PRs. The cache key is just a shasum of the directory contents, which doesn't account for docker versions. It looks like docker doesn't reuse some caches here. That in turn means that the cache key from an old build isn't reusable by this PR. This PR's caches aren't usable by other PR's caches. If this PR alternates with another (which almost always happens for spurious failures retried) then we're going back and forth timing out. I'm gonna fix this by throwing |
In theory we shouldn't require trusty so long as docker continues to work!
a635127
to
66f0e42
Compare
@bors: r=kennytm |
📌 Commit 66f0e42 has been approved by |
ci: Upgrade Travis to Xenial In theory we shouldn't require trusty so long as docker continues to work!
💔 Test failed - status-travis |
Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@bors: retry |
⌛ Testing commit 66f0e42 with merge dcc5ccfefa5e656cfc86c89ca508d2e7645617d6... |
💔 Test failed - status-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@bors: retry That's the one expected time out here |
ci: Upgrade Travis to Xenial In theory we shouldn't require trusty so long as docker continues to work!
☀️ Test successful - status-appveyor, status-travis |
In theory we shouldn't require trusty so long as docker continues to
work!