-
Notifications
You must be signed in to change notification settings - Fork 667
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
Docker cross test infrastructure #297
Docker cross test infrastructure #297
Conversation
c99f5c3
to
65ede19
Compare
I am really excited to look at this! |
Could we prefer software emulation? That's what libc does for freebsd / netbsd / android on ARM. Travis can't even give us /dev/kvm if they wanted to: it's not available on GCE where they run. Or on EC2 for that matter... |
# Tell cargo what linker to use and whatever else is required | ||
# | ||
configure_cargo() { | ||
rm -rf .cargo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems potentially destructive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Currently, this is only executed in the container (and not in a directory that is part of a shared volume) -- May need to re-evaluate depending on how things evolve.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I mean that if I accidentally run this from the top level, and I have some cargo config, I will lose it. since I keep those out of git, I would then be sad.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eg, I'd rather save the existing one, and have a trap to put the original back on exit or error
Couple of comments so far. I'm somewhere with slow internet, and so I can't play with it because pulling the image will take a while. |
I think we can. I am just getting around to actually testing the qemu bits and will give it a good try. I'l have some time free next week (changing day jobs and have a week off), so I should have some time to round out testing and get things ready to go for travis. |
👍 @posborne do you want to get this merged sooner than later? |
@kamalmarhubi I am going to take one more pass at it, but then I would like to get something into master so people can start testing/fixing on various issues. Phase 2 will be figuring out how best to integrate it with CI -- We will probably need to dump travis-rust-matrix, but that has been showing some strain lately anyhow. I'm rebuilding the docker image right now as several dependencies were missing previously (the image is quite large now as the qemu-* packages are not small). |
These scripts represent a rough first cust at adding support for locally building nix and its tests for a large number of rust versions and architectures. Currently, this mostly helps with testing that nix compiles for various architectures (to the point that there are a mound of problems that need to be addressed). Once these are sorted, the code for actually running the tests for various architectures will be approached (this will require qemu and will still not target all architectures). Signed-off-by: Paul Osborne <osbpau@gmail.com>
Signed-off-by: Paul Osborne <osbpau@gmail.com>
Signed-off-by: Paul Osborne <osbpau@gmail.com>
There is now a published docker image (if a bit large) making it possible for others to start using the new test ingfrastructure. There seems to be no shortage of compile problems right now. Signed-off-by: Paul Osborne <osbpau@gmail.com>
This is handy for trying out changes to the docker image for testing things out. Signed-off-by: Paul Osborne <osbpau@gmail.com>
Signed-off-by: Paul Osborne <osbpau@gmail.com>
Later on, it will probably make sense to stop on failure -- given that most targets currently fail, however, this works a bit better for the time being. Signed-off-by: Paul Osborne <osbpau@gmail.com>
Signed-off-by: Paul Osborne <osbpau@gmail.com>
Signed-off-by: Paul Osborne <osbpau@gmail.com>
We already need to test cargo about gcc locations so it can perfom linking -- we just parse this information out to tell rust where gcc is for complation (nix-test compiles some C code for testing). Signed-off-by: Paul Osborne <osbpau@gmail.com>
There are also changes in the upstream docker images to support more targets (android on ARM, etc).
bdefc80
to
b69558c
Compare
The rust-cross image is no longer all-in-one but broken out by architecture class (or platform in the case of android). Signed-off-by: Paul Osborne <osbpau@gmail.com>
b338ccc
to
f9371fc
Compare
This is based on libc and the new docker-based testing infrastructure via posborne/rust-cross. Signed-off-by: Paul Osborne <osbpau@gmail.com>
f9371fc
to
6ad81d1
Compare
All of the platforms tested currently fail in some way currently, but the infrastructure itself appears to be working. As we have moved to the legacy infrastructure (required in order to use docker), the tests do run slower now. To compensate for that, i686 builds are only done on stable and we do not test every version between the current stable and the oldest version we support. Signed-off-by: Paul Osborne <osbpau@gmail.com>
3d7bac4
to
3b7b15d
Compare
Ok, things seem to be working, so I think this is ready for a review. I have the extra platforms tested set to not fail things right now until we get things sorted. As we fix things, we can remove those versions from the |
@@ -20,7 +20,7 @@ preadv_pwritev = [] | |||
signalfd = [] | |||
|
|||
[dependencies] | |||
libc = "0.2.8" | |||
libc = { git = "https://github.com/rust-lang/libc.git" } | |||
bitflags = "0.4" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooops, I will remove this. I had this locally for testing and it slipped in.
Signed-off-by: Paul Osborne <osbpau@gmail.com>
Based on code review feedback. Signed-off-by: Paul Osborne <osbpau@gmail.com>
For platforms where the host ${CC} is appropriate, use the default implicitly rather than matching it explictly. This will allow for the llvm linker to be used if/when that happens. Signed-off-by: Paul Osborne <osbpau@gmail.com>
Signed-off-by: Paul Osborne <osbpau@gmail.com>
Signed-off-by: Paul Osborne <osbpau@gmail.com>
On the host, some undesired things could end up happening if this is executed, so we now exit and log if that is attempted. In addition, we now backup the previous cargo config if present. This will never be the case in the current build setup, but that could change if we decide to do builds in a data volume in the future. Signed-off-by: Paul Osborne <osbpau@gmail.com>
0ed9167
to
d1311ff
Compare
awesome!!! @homu r+ |
📌 Commit d1311ff has been approved by |
⚡ Test exempted - status |
…almarhubi Docker cross test infrastructure These commits contain the first portion of new infrastructure that will allow us to build for and test on a much larger set of platforms. Nix and the tests are *not* compiling on many platforms right now, but I believe at this point that most of those problems are issues with nix (or libc) rather than the test infrastructure. I want to get this out there so we can start filing issues and other people can start doing testing and development to resolve the issues popping up on various platforms. None of this is integrated in with travis at this point -- that will be phase 3. Phase 2 will be getting qemu going to run the tests for non-host platforms (this might be tricky when running in a container as `/dev/kvm` might need to be passed through). This is based on the testing infrastructure in libc but modified quite a bit -- The libc infrastructure doesn't seem to be a great experience for testing locally. If this approach works out, we might want to push this approach toward libc. The Dockerfile/Image that goes along with this is currently here: * https://github.com/posborne/docker-rust-cross * https://hub.docker.com/r/posborne/rust-cross/ I would have no problem moving this into the org if that makes sense down the line.
These commits contain the first portion of new infrastructure that will allow us to build for and test on a much larger set of platforms. Nix and the tests are not compiling on many platforms right now, but I believe at this point that most of those problems are issues with nix (or libc) rather than the test infrastructure.
I want to get this out there so we can start filing issues and other people can start doing testing and development to resolve the issues popping up on various platforms. None of this is integrated in with travis at this point -- that will be phase 3. Phase 2 will be getting qemu going to run the tests for non-host platforms (this might be tricky when running in a container as
/dev/kvm
might need to be passed through).This is based on the testing infrastructure in libc but modified quite a bit -- The libc infrastructure doesn't seem to be a great experience for testing locally. If this approach works out, we might want to push this approach toward libc.
The Dockerfile/Image that goes along with this is currently here:
I would have no problem moving this into the org if that makes sense down the line.