travis: Split the linux-tested-targets builder #40382
Conversation
alexcrichton
force-pushed
the
split-tested-targets
branch
from
2463e7c
to
7f28d14
Compare
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
Can't we change compiletest to remove binaries after it runs them? |
|
Heh in theory yes! We can do w/e we like. I don't think that's a feature we want to add though because I've at least often found it useful to inspect binaries after-the-fact. We've got extra capacity and in general this was just easier to implement. |
|
@bors r+ p=1 |
|
📌 Commit 7f28d14 has been approved by |
|
@bors: p=100000000 |
|
🔒 Merge conflict |
alexcrichton
force-pushed
the
split-tested-targets
branch
from
7f28d14
to
5a4e60f
Compare
|
@bors: r=brson |
|
📌 Commit 5a4e60f has been approved by |
|
⌛ Testing commit 5a4e60f with merge 9e9f0a5... |
|
💔 Test failed - status-travis |
Travis only gives us 30GB disk space and we don't currently have an option to increase that. Each musl target generates "hello world" binaries of about 3.5MB in size, and we're testing two targets in the same image. We have around 3k run-pass tests and 2 musl targets which works out to around 20GB. That's dangerously close to the limit and is causing PRs to bounce. This PR splits up the builder in two, one for x86_64 musl and the other for i686. Hopefully that'll keep us under the disk limit. Closes rust-lang#40359
alexcrichton
force-pushed
the
split-tested-targets
branch
from
5a4e60f
to
f44801c
Compare
|
@bors: r=brson |
|
📌 Commit f44801c has been approved by |
|
⌛ Testing commit f44801c with merge 29fd7ee... |
|
💔 Test failed - status-travis |
|
@bors retry there's not even a mac log here |
travis: Split the linux-tested-targets builder Travis only gives us 30GB disk space and we don't currently have an option to increase that. Each musl target generates "hello world" binaries of about 3.5MB in size, and we're testing two targets in the same image. We have around 3k run-pass tests and 2 musl targets which works out to around 20GB. That's dangerously close to the limit and is causing PRs to bounce. This PR splits up the builder in two, one for x86_64 musl and the other for i686. Hopefully that'll keep us under the disk limit. Closes #40359
|
☀️ Test successful - status-appveyor, status-travis |
Travis only gives us 30GB disk space and we don't currently have an option to
increase that. Each musl target generates "hello world" binaries of about 3.5MB
in size, and we're testing two targets in the same image. We have around 3k
run-pass tests and 2 musl targets which works out to around 20GB. That's
dangerously close to the limit and is causing PRs to bounce.
This PR splits up the builder in two, one for x86_64 musl and the other for
i686. Hopefully that'll keep us under the disk limit.
Closes #40359