about summary refs log tree commit diff
path: root/src/ci
AgeCommit message (Collapse)AuthorLines
2016-12-29rustbuild: Don't run pretty tests by defaultAlex Crichton-1/+1
This commit relegates all pretty tests to not get run by default and rather get run as part of an "aux" test suite. This "aux" suite is renamed from the old "cargotest" suite to just collect tests that don't need to run everywhere but should at least pass on Unix/Windows.
2016-12-28rustbuild: Compile rustc twice, not thriceAlex Crichton-0/+28
This commit switches the rustbuild build system to compiling the compiler twice for a normal bootstrap rather than the historical three times. Rust is a bootstrapped language which means that a previous version of the compiler is used to build the next version of the compiler. Over time, however, we change many parts of compiler artifacts such as the metadata format, symbol names, etc. These changes make artifacts from one compiler incompatible from another compiler. Consequently if a compiler wants to be able to use some artifacts then it itself must have compiled the artifacts. Historically the rustc build system has achieved this by compiling the compiler three times: * An older compiler (stage0) is downloaded to kick off the chain. * This compiler now compiles a new compiler (stage1) * The stage1 compiler then compiles another compiler (stage2) * Finally, the stage2 compiler needs libraries to link against, so it compiles all the libraries again. This entire process amounts in compiling the compiler three times. Additionally, this process always guarantees that the Rust source tree can compile itself because the stage2 compiler (created by a freshly created compiler) would successfully compile itself again. This property, ensuring Rust can compile itself, is quite important! In general, though, this third compilation is not required for general purpose development on the compiler. The third compiler (stage2) can reuse the libraries that were created during the second compile. In other words, the second compilation can produce both a compiler and the libraries that compiler will use. These artifacts *must* be compatible due to the way plugins work today anyway, and they were created by the same source code so they *should* be compatible as well. So given all that, this commit switches the default build process to only compile the compiler three times, avoiding this third compilation by copying artifacts from the previous one. Along the way a new entry in the Travis matrix was also added to ensure that our full bootstrap can succeed. This entry does not run tests, though, as it should not be necessary. To restore the old behavior of a full bootstrap (three compiles) you can either pass: ./configure --enable-full-bootstrap or if you're using config.toml: [build] full-bootstrap = true Overall this will hopefully be an easy 33% win in build times of the compiler. If we do 33% less work we should be 33% faster! This in turn should affect cycle times and such on Travis and AppVeyor positively as well as making it easier to work on the compiler itself.
2016-12-26travis: Remove extraneous /tmp/obj dirsAlex Crichton-26/+0
These are no longer used when running containers and tests.
2016-12-26travis: Don't install ccache in containersAlex Crichton-12/+0
We no longer use it, we use sccache
2016-12-26travis: Attempt to fix Android flakinessAlex Crichton-1/+3
There's been some flaky runs on Travis where the Android emulator is having problems staying alive... presumably? For example: * https://travis-ci.org/rust-lang/rust/jobs/186736745 This commit spawns the emulator in the same way as buildbot with `nohup` to hope that it goes into the background successfully, followed by a `wait-for-device` command. I'm not actually sure if this'll fix the problems we're seeing, but I figure it can't hurt to test out.
2016-12-20Merge branch 'local-sccache' of https://github.com/alexcrichton/rust into rollupAlex Crichton-3/+11
2016-12-19travis: Support local sccache if not on botsAlex Crichton-3/+11
This commit configures local sccache directory to get used if you're running builds locally to enjoy the benefits of caching when running inside the containers.
2016-12-19travis: Fix the cargotest botAlex Crichton-1/+2
Recently the Cargo revision running on cargotest was updated in #38051, and the updated version of Cargo pulls in the openssl-sys 0.9 crate instead of the old openssl-sys 0.7 crate. The 0.9 release of openssl-sys has slightly different requirements and logic for detecting OpenSSL, namely it requires `pkg-config` to be present on Linux typically. This commit fixes this problem by installing pkg-config in the cargotest container that's running on the bots. This in turn should hopefully fix the build script and allow it to find the already-installed local OpenSSL libraries.
2016-12-14rustbuild: Add sccache supportAlex Crichton-18/+72
This commit adds support for sccache, a ccache-like compiler which works on MSVC and stores results into an S3 bucket. This also switches over all Travis and AppVeyor automation to using sccache to ensure a shared and unified cache over time which can be shared across builders. The support for sccache manifests as a new `--enable-sccache` option which instructs us to configure LLVM differently to use a 'sccache' binary instead of a 'ccache' binary. All docker images for Travis builds are updated to download Mozilla's tooltool builds of sccache onto various containers and systems. Additionally a new `rust-lang-ci-sccache` bucket is configured to hold all of our ccache goodies.
2016-12-13Fix travis buildsAlex Crichton-1/+61
After reading some articles [1] [2] yesterday about Docker and the "init" process I got to thinking about the problems that we've been seeing on Travis. The basic problem is that a Linux system may need an "init" process to work properly when processes become zombies. Docker by default doesn't handle this and the root process typically isn't an init process, so this can occasionally cause quite a few problems. We've been seeing spurious errors on Travis inside containers which look like OOM and such, but my guess is that zombie processes were being reparented to the top-level shell. The shell didn't expect the zombies and then behaved very strangely. This commit fixes these problems by using Yelp's "dumb-init" program [2] as the init process in all of our containers. This ensures that there's a valid init ready to reap children when they're reparented, which our test suite apparently generates a bunch of throughout the tests and such. [1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ [2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html
2016-12-07mk: Switch rustbuild to the default build systemAlex Crichton-24/+35
This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md`, `CONTRIBUTING.md`, `src/bootstrap/README.md`, and throughout the source code of rustbuild itself. Closes #37858
2016-11-11Move all Linux/OSX CI infastructure to TravisAlex Crichton-0/+655
This commit configures our `.travis.yml` to test the full suite of tests we have on Buildbot right now. A whole mess of docker images are added to the `src/ci` directory which represent all the build environments for each configuration. Each of these environments is then configured in `.travis.yml` to run on the auto branch. Note that the full matrix of tests aren't intended to be run on all PRs. Instead, we continue to run only one entry in the matrix, forcing all others to finish quickly. Only the `auto` branch should run the full matrix of builds. Also note that the infrastructure hasn't quite been allocated yet to the rust-lang/rust repository, so everything is disabled for now except for the one build that happens on PRs. Once that infrastructure is allocated though we can enable this and let it fly! Notable modifications from the current test suite today: * Android tests are run in rustbuild instead of the makefiles, for whatever reason I couldn't get the makefiles to work on Travis. * A debuginfo test was updated to work with the current version of the Android NDK. * Some dependencies in `mk/tests.mk` were fixed to allow running tests in parallel.