mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7bed84f17e
rust/.travis.yml

224 lines
7.3 KiB
YAML
Raw Normal View History

mk: Switch rustbuild to the default build system 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-16 14:31:19 -06:00
language: minimal
Tweak Travis to use GCE Travis CI has new infrastructure using the Google Compute Engine which has both faster CPUs and more memory, and we've been encouraged to switch as it should help our build times! The only downside currently, however, is that IPv6 is disabled, causing a number of standard library tests to fail. Consequently this commit tweaks our travis config in a few ways: * ccache is disabled as it's not working on GCE just yet * Docker is used to run tests inside which reportedly will get IPv6 working * A system LLVM installation is used instead of building LLVM itself. This is primarily done to reduce build times, but we want automation for this sort of behavior anyway and we can extend this in the future with building from source as well if needed. * gcc-specific logic is removed as the docker image for Ubuntu gives us a recent-enough gcc by default.
2015-09-18 12:19:23 -05:00
sudo: required
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
dist: trusty
Use Docker for Travis
2016-06-01 10:14:22 -05:00
services:
- docker
Add a Travis-CI configuration for the repo Travis CI provides an easy-to-use continuous integration infrastructure for github repos to use. Travis will automatically test all PRs which are opened against the rust repository, informing PR owners of the test results. I believe that this will be a very convenient piece of infrastructure as we'll be able to reduce the load on bors quite a bit. In theory all PRs opened have had the full test suite run against them, but unfortunately this is rarely the case (I'm a prime suspect). Travis will be able to provide easy and relatively quick (~30min) feedback for PRs. By ensuring fewer failures on bors, we can hopefully feed more successful jobs to bors. Overall, I expect this to be very helpful for new contributors as well as regular contributors as it's another layer of tests being run which will hopefully catch things sooner. One of the most convenient parts about using Travis is that there's very little burden in terms of maintenance, and if things go wrong we can easily turn travis completely off. Note that this is *not* the metric by which a PR will be merged with. Using travis will purely be another source for running tests, we will continue to gate all PRs on bors.
2014-02-20 17:37:44 -06:00
Tweak Travis to use GCE Travis CI has new infrastructure using the Google Compute Engine which has both faster CPUs and more memory, and we've been encouraged to switch as it should help our build times! The only downside currently, however, is that IPv6 is disabled, causing a number of standard library tests to fail. Consequently this commit tweaks our travis config in a few ways: * ccache is disabled as it's not working on GCE just yet * Docker is used to run tests inside which reportedly will get IPv6 working * A system LLVM installation is used instead of building LLVM itself. This is primarily done to reduce build times, but we want automation for this sort of behavior anyway and we can extend this in the future with building from source as well if needed. * gcc-specific logic is removed as the docker image for Ubuntu gives us a recent-enough gcc by default.
2015-09-18 12:19:23 -05:00
git:
Reduce git clone --depth from 50 to 1
2016-07-28 04:48:43 -05:00
depth: 1
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
submodules: false
Ratchet up travis to build stage1 and our own LLVM. Tidy is still run first for failing fast on the easy stuff. To accomplish this we have travis actually persist ccache across builds. This has LLVM built within 6 minutes, and all of stage1 built within 18. Caching should work on fresh PRs (cache acquired from the master branch). Because all we persist is ccache, there is minimal danger of persisting corrupt build state. I had to mangle `configure` a bit to make --enable-ccache work when custom compilers are provide via CC and CXX.
2015-07-13 19:29:01 -05:00
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
matrix:
More test fixes from rollup
2017-01-19 19:18:12 -06:00
fast_finish: true
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
include:
# Linux builders, all docker images
travis: Split Android into dist/test images PRs can't land againt beta right now because the android bot is filling up on disk space. I don't really know what's going on but the android bot is the longest one to run anyway so it'll benefit from being split up regardless.
2017-02-27 16:53:12 -06:00
- env: IMAGE=arm-android
Add support for test suites emulated in QEMU This commit adds support to the build system to execute test suites that cannot run natively but can instead run inside of a QEMU emulator. A proof-of-concept builder was added for the `arm-unknown-linux-gnueabihf` target to show off how this might work. In general the architecture is to have a server running inside of the emulator which a local client connects to. The protocol between the server/client supports compiling tests on the host and running them on the target inside the emulator. Closes #33114
2017-01-28 15:38:06 -06:00
- env: IMAGE=armhf-gnu
travis: Start uploading artifacts on commits This commit starts adding the infrastructure for uploading release artifacts from AppVeyor/Travis on each commit. The idea is that eventually we'll upload a full release to AppVeyor/Travis in accordance with plans [outlined earlier]. Right now this configures Travis/Appveyor to upload all tarballs in the `dist` directory, and various images are updated to actually produce tarballs in these directories. These are nowhere near ready to be actual release artifacts, but this should allow us to play around with it and test it out. Once this commit lands we should start seeing artifacts uploaded on each commit. [outlined earlier]: https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489
2016-12-31 19:42:40 -06:00
- env: IMAGE=cross DEPLOY=1
travis: Split Android into dist/test images PRs can't land againt beta right now because the android bot is filling up on disk space. I don't really know what's going on but the android bot is the longest one to run anyway so it'll benefit from being split up regardless.
2017-02-27 16:53:12 -06:00
- env: IMAGE=dist-android DEPLOY=1
travis: Expand dist builder coverage This commit adds six new travis matrix entires for doing cross-compiled distribution builds of the compiler. The support added in #38731 allows us to quickly compile a complete suite of distribution artifacts for cross-compiled platforms, and currently each matrix entry (when fully cached) clocks in around an hour to finish. Note that a full test run typically takes about two hours right now. With further optimizations coming down the pike in #39026 this commit also starts doubling up cross-compiled distribution builders on each matrix entry. We initially planned to do one build per entry, but it's looking like we may be able to get by with more than one in each entry. Depending on how long these builds take we may even be able to up it to three, but we'll start with two first. This commit then completes the suite of cross-compiled compilers that we're going to compile, adding it for a whole litany of platforms detailed in the changes to the docker files here. The existing `cross` image is also trimmed down quite a bit to avoid duplicate work, and we'll eventually provision it for far more cross compilation as well. Note that the gcc toolchains installed to compile most of these compilers are inappropriate for actualy distribution. The glibc they pull in is much newer than we'd like, so before we turn nightlies off we'll need to tweak these docker files to custom build toolchains like the current `linux-cross` docker image does.
2017-01-13 11:18:09 -06:00
- env: IMAGE=dist-arm-linux DEPLOY=1
- env: IMAGE=dist-armv7-aarch64-linux DEPLOY=1
- env: IMAGE=dist-freebsd DEPLOY=1
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
2017-03-08 21:46:44 -06:00
- env: IMAGE=dist-i586-gnu-i686-musl DEPLOY=1
travis: Fuchsia builder This change introduces a Dockerfile and script which builds a complete Fuchsia toolchain which can be used to build Rust distribution for Fuchsia. We only support cross-compiling at the moment, hence only setting the target.
2017-02-16 22:54:24 -06:00
- env: IMAGE=dist-fuchsia DEPLOY=1
travis: Expand dist builder coverage This commit adds six new travis matrix entires for doing cross-compiled distribution builds of the compiler. The support added in #38731 allows us to quickly compile a complete suite of distribution artifacts for cross-compiled platforms, and currently each matrix entry (when fully cached) clocks in around an hour to finish. Note that a full test run typically takes about two hours right now. With further optimizations coming down the pike in #39026 this commit also starts doubling up cross-compiled distribution builders on each matrix entry. We initially planned to do one build per entry, but it's looking like we may be able to get by with more than one in each entry. Depending on how long these builds take we may even be able to up it to three, but we'll start with two first. This commit then completes the suite of cross-compiled compilers that we're going to compile, adding it for a whole litany of platforms detailed in the changes to the docker files here. The existing `cross` image is also trimmed down quite a bit to avoid duplicate work, and we'll eventually provision it for far more cross compilation as well. Note that the gcc toolchains installed to compile most of these compilers are inappropriate for actualy distribution. The glibc they pull in is much newer than we'd like, so before we turn nightlies off we'll need to tweak these docker files to custom build toolchains like the current `linux-cross` docker image does.
2017-01-13 11:18:09 -06:00
- env: IMAGE=dist-mips-linux DEPLOY=1
- env: IMAGE=dist-mips64-linux DEPLOY=1
- env: IMAGE=dist-powerpc-linux DEPLOY=1
- env: IMAGE=dist-powerpc64-linux DEPLOY=1
- env: IMAGE=dist-s390x-linux-netbsd DEPLOY=1
travis: Move glibc backwards in time This commit updates the compilers for many of the artifacts that we're producing on Travis. These compilers are all compiled by crosstool-ng as they're currently done for the images in which we're building all our cross compiled compilers. The purpose of this commit is that when we ship binaries the artifacts won't require a newer glibc, but rather be as compatible as possible with Linux distributions by working with a very old version of glibc. This commit always allocates a new matrix entry for the i686/x86_64 builder. This builder is dedicated to just producing artifacts and eventually we'll expand it to building other tools like Cargo and the RLS. The other builders testing i686 and x86_64 won't use these historical toolchains.
2017-01-18 18:04:22 -06:00
- env: IMAGE=dist-x86-linux DEPLOY=1
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
2017-03-08 21:46:44 -06:00
- env: IMAGE=dist-x86_64-musl DEPLOY=1
More test fixes from rollup
2017-01-19 19:18:12 -06:00
- env: IMAGE=emscripten
travis: Move glibc backwards in time This commit updates the compilers for many of the artifacts that we're producing on Travis. These compilers are all compiled by crosstool-ng as they're currently done for the images in which we're building all our cross compiled compilers. The purpose of this commit is that when we ship binaries the artifacts won't require a newer glibc, but rather be as compatible as possible with Linux distributions by working with a very old version of glibc. This commit always allocates a new matrix entry for the i686/x86_64 builder. This builder is dedicated to just producing artifacts and eventually we'll expand it to building other tools like Cargo and the RLS. The other builders testing i686 and x86_64 won't use these historical toolchains.
2017-01-18 18:04:22 -06:00
- env: IMAGE=i686-gnu
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
- env: IMAGE=i686-gnu-nopt
travis: Move glibc backwards in time This commit updates the compilers for many of the artifacts that we're producing on Travis. These compilers are all compiled by crosstool-ng as they're currently done for the images in which we're building all our cross compiled compilers. The purpose of this commit is that when we ship binaries the artifacts won't require a newer glibc, but rather be as compatible as possible with Linux distributions by working with a very old version of glibc. This commit always allocates a new matrix entry for the i686/x86_64 builder. This builder is dedicated to just producing artifacts and eventually we'll expand it to building other tools like Cargo and the RLS. The other builders testing i686 and x86_64 won't use these historical toolchains.
2017-01-18 18:04:22 -06:00
- env: IMAGE=x86_64-gnu
rustbuild: Compile rustc twice, not thrice 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-25 17:20:33 -06:00
- env: IMAGE=x86_64-gnu-full-bootstrap
rustbuild: Don't run pretty tests by default 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-29 11:55:16 -06:00
- env: IMAGE=x86_64-gnu-aux
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
- env: IMAGE=x86_64-gnu-debug
- env: IMAGE=x86_64-gnu-nopt
Set `RUST_BACKTRACE=1` on travis to be more helpful.
2016-11-10 08:12:53 -06:00
- env: IMAGE=x86_64-gnu-llvm-3.7 ALLOW_PR=1 RUST_BACKTRACE=1
travis: Add a distcheck target This commit adds a new entry to the Travis matrix which performs a "distcheck", which basically means that we create a tarball, extract that tarball, and then build/test inside there. This ensures that the tarballs we produce are actually able to be built/tested! Along the way this also updates the rustbuild distcheck definition to propagate the configure args from the top-level invocation. Closes #38691
2016-12-30 11:26:25 -06:00
- env: IMAGE=x86_64-gnu-distcheck
travis: Gate on some minimal support for incremental compilation. This commit adds a travis job that builds a stage2 compiler in incremental mode (but with empty incremental compilation cache). Building incrementally with an empty cache makes sure that the compiler doesn't crash in dependency tracking during bootstrapping.
2017-01-05 08:02:14 -06:00
- env: IMAGE=x86_64-gnu-incremental
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
# OSX builders
- env: >
RUST_CHECK_TARGET=check
travis: Fix testing 32-bit OSX target We passed --target when we meant to pass --build, meaning we tested only the standard library for 32-bit, not the whole compiler like we intended.
2016-12-16 18:32:40 -06:00
RUST_CONFIGURE_ARGS=--build=x86_64-apple-darwin
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
SRC=.
rustc: Support auto-retry linking on a segfault This is a last-ditch attempt to help our pain with dealing with #38878 on the bots. A new environment variable is added to the compiler, `RUSTC_RETRY_LINKER_ON_SEGFAULT`, which will instruct the compiler to automatically retry the final linker invocation if it looks like the linker segfaulted (up to 2 extra times). Unfortunately there have been no successful attempts to debug #38878. The only information seems to be that the linker (e.g. `ld` on OSX) is segfaulting somewhere in some thread pool implementation. This appears to be spurious as failed PRs will later merge. The hope is that this helps the queue keep moving without clogging and delaying PRs due to #38878.
2017-03-10 11:04:27 -06:00
RUSTC_RETRY_LINKER_ON_SEGFAULT=1
Attempt to debug sccache in more locations This should hopefully add support for debugging OSX and Windows presumed sccache failures instead of just the Linux ones.
2017-03-11 11:06:44 -06:00
SCCACHE_ERROR_LOG=/tmp/sccache.log
Target builds for older macOS
2017-03-13 13:36:44 -05:00
MACOSX_DEPLOYMENT_TARGET=10.8
MACOSX_STD_DEPLOYMENT_TARGET=10.7
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
os: osx
travis: Tweak OSX image configuration Somewhere between https://travis-ci.org/rust-lang/rust/jobs/192352185 and https://travis-ci.org/rust-lang/rust/jobs/192440181 it looks like our configuration for a newer OSX image was lost as LLDB has reverted itself back to 350. This fix appeared to work for the libc crate so let's see if we can configure it to work for the rust repo as well.
2017-01-16 20:43:38 -06:00
osx_image: xcode8.2
rustbuild: Add sccache support 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-12 13:36:52 -06:00
install: &osx_install_sccache >
travis: Update sccache binary I've built a local copy with mozilla/sccache#79 and mozilla/sccache#78. Let's see if that helps #40240!
2017-03-16 09:55:15 -05:00
travis_retry curl -o /usr/local/bin/sccache https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-03-16-sccache-x86_64-apple-darwin &&
travis: Add timestamps to all build messages When debugging why builds are taking so long it's often useful to get the timestamp of all log messages as we're not always timing every tiny step of the build. I wrote a [utility] for prepending a relative timestamp from the start of a process which is now downloaded to the builders and is what we wrap the entire build invocation in. [utility]: https://github.com/alexcrichton/stamp-rs Closes #40577
2017-03-17 11:31:28 -05:00
chmod +x /usr/local/bin/sccache &&
travis_retry curl -o /usr/local/bin/stamp https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-03-17-stamp-x86_64-apple-darwin &&
chmod +x /usr/local/bin/stamp
Automatically vendor Cargo deps when building the source tarballs.
2017-02-10 14:59:40 -06:00
- env: >
RUST_CHECK_TARGET=check
RUST_CONFIGURE_ARGS=--build=i686-apple-darwin
SRC=.
rustc: Support auto-retry linking on a segfault This is a last-ditch attempt to help our pain with dealing with #38878 on the bots. A new environment variable is added to the compiler, `RUSTC_RETRY_LINKER_ON_SEGFAULT`, which will instruct the compiler to automatically retry the final linker invocation if it looks like the linker segfaulted (up to 2 extra times). Unfortunately there have been no successful attempts to debug #38878. The only information seems to be that the linker (e.g. `ld` on OSX) is segfaulting somewhere in some thread pool implementation. This appears to be spurious as failed PRs will later merge. The hope is that this helps the queue keep moving without clogging and delaying PRs due to #38878.
2017-03-10 11:04:27 -06:00
RUSTC_RETRY_LINKER_ON_SEGFAULT=1
Attempt to debug sccache in more locations This should hopefully add support for debugging OSX and Windows presumed sccache failures instead of just the Linux ones.
2017-03-11 11:06:44 -06:00
SCCACHE_ERROR_LOG=/tmp/sccache.log
Target builds for older macOS
2017-03-13 13:36:44 -05:00
MACOSX_DEPLOYMENT_TARGET=10.8
MACOSX_STD_DEPLOYMENT_TARGET=10.7
Automatically vendor Cargo deps when building the source tarballs.
2017-02-10 14:59:40 -06:00
os: osx
osx_image: xcode8.2
install: *osx_install_sccache
travis: Attempt to debug OSX linker segfaults This commit attempts to debug the segfaults that we've been seeing on OSX on Travis. I have no idea what's going on here mostly, but let's try to look at core dumps and get backtraces to see what's going on. This commit itself is mostly a complete shot in the dark, I'm not sure if this even works... cc #38878
2017-01-12 16:58:55 -06:00
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
- env: >
Automatically vendor Cargo deps when building the source tarballs.
2017-02-10 14:59:40 -06:00
RUST_CHECK_TARGET=dist
rustbuild: Start building --enable-extended This commit adds a new flag to the configure script, `--enable-extended`, which is intended for specifying a desire to compile the full suite of Rust tools such as Cargo, the RLS, etc. This is also an indication that the build system should create combined installers such as the pkg/exe/msi artifacts. Currently the `--enable-extended` flag just indicates that combined installers should be built, and Cargo is itself not compiled just yet but rather only downloaded from its location. The intention here is to quickly get to feature parity with the current release process and then we can start improving it afterwards. All new files in this PR inside `src/etc/installer` are copied from the rust-packaging repository.
2017-01-20 19:03:06 -06:00
RUST_CONFIGURE_ARGS="--build=i686-apple-darwin --enable-extended"
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
SRC=.
travis: Start uploading artifacts on commits This commit starts adding the infrastructure for uploading release artifacts from AppVeyor/Travis on each commit. The idea is that eventually we'll upload a full release to AppVeyor/Travis in accordance with plans [outlined earlier]. Right now this configures Travis/Appveyor to upload all tarballs in the `dist` directory, and various images are updated to actually produce tarballs in these directories. These are nowhere near ready to be actual release artifacts, but this should allow us to play around with it and test it out. Once this commit lands we should start seeing artifacts uploaded on each commit. [outlined earlier]: https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489
2016-12-31 19:42:40 -06:00
DEPLOY=1
rustc: Support auto-retry linking on a segfault This is a last-ditch attempt to help our pain with dealing with #38878 on the bots. A new environment variable is added to the compiler, `RUSTC_RETRY_LINKER_ON_SEGFAULT`, which will instruct the compiler to automatically retry the final linker invocation if it looks like the linker segfaulted (up to 2 extra times). Unfortunately there have been no successful attempts to debug #38878. The only information seems to be that the linker (e.g. `ld` on OSX) is segfaulting somewhere in some thread pool implementation. This appears to be spurious as failed PRs will later merge. The hope is that this helps the queue keep moving without clogging and delaying PRs due to #38878.
2017-03-10 11:04:27 -06:00
RUSTC_RETRY_LINKER_ON_SEGFAULT=1
Attempt to debug sccache in more locations This should hopefully add support for debugging OSX and Windows presumed sccache failures instead of just the Linux ones.
2017-03-11 11:06:44 -06:00
SCCACHE_ERROR_LOG=/tmp/sccache.log
Target builds for older macOS
2017-03-13 13:36:44 -05:00
MACOSX_DEPLOYMENT_TARGET=10.8
MACOSX_STD_DEPLOYMENT_TARGET=10.7
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
os: osx
travis: Tweak OSX image configuration Somewhere between https://travis-ci.org/rust-lang/rust/jobs/192352185 and https://travis-ci.org/rust-lang/rust/jobs/192440181 it looks like our configuration for a newer OSX image was lost as LLDB has reverted itself back to 350. This fix appeared to work for the libc crate so let's see if we can configure it to work for the rust repo as well.
2017-01-16 20:43:38 -06:00
osx_image: xcode8.2
travis: Don't enable quiet tests This makes travis problems more difficult to debug, so let's just enable more verbose logging.
2017-03-17 11:33:34 -05:00
install: *osx_install_sccache
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
- env: >
travis: Start uploading artifacts on commits This commit starts adding the infrastructure for uploading release artifacts from AppVeyor/Travis on each commit. The idea is that eventually we'll upload a full release to AppVeyor/Travis in accordance with plans [outlined earlier]. Right now this configures Travis/Appveyor to upload all tarballs in the `dist` directory, and various images are updated to actually produce tarballs in these directories. These are nowhere near ready to be actual release artifacts, but this should allow us to play around with it and test it out. Once this commit lands we should start seeing artifacts uploaded on each commit. [outlined earlier]: https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489
2016-12-31 19:42:40 -06:00
RUST_CHECK_TARGET=dist
rustbuild: Start building --enable-extended This commit adds a new flag to the configure script, `--enable-extended`, which is intended for specifying a desire to compile the full suite of Rust tools such as Cargo, the RLS, etc. This is also an indication that the build system should create combined installers such as the pkg/exe/msi artifacts. Currently the `--enable-extended` flag just indicates that combined installers should be built, and Cargo is itself not compiled just yet but rather only downloaded from its location. The intention here is to quickly get to feature parity with the current release process and then we can start improving it afterwards. All new files in this PR inside `src/etc/installer` are copied from the rust-packaging repository.
2017-01-20 19:03:06 -06:00
RUST_CONFIGURE_ARGS="--target=aarch64-apple-ios,armv7-apple-ios,armv7s-apple-ios,i386-apple-ios,x86_64-apple-ios --enable-extended"
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
SRC=.
travis: Start uploading artifacts on commits This commit starts adding the infrastructure for uploading release artifacts from AppVeyor/Travis on each commit. The idea is that eventually we'll upload a full release to AppVeyor/Travis in accordance with plans [outlined earlier]. Right now this configures Travis/Appveyor to upload all tarballs in the `dist` directory, and various images are updated to actually produce tarballs in these directories. These are nowhere near ready to be actual release artifacts, but this should allow us to play around with it and test it out. Once this commit lands we should start seeing artifacts uploaded on each commit. [outlined earlier]: https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489
2016-12-31 19:42:40 -06:00
DEPLOY=1
rustc: Support auto-retry linking on a segfault This is a last-ditch attempt to help our pain with dealing with #38878 on the bots. A new environment variable is added to the compiler, `RUSTC_RETRY_LINKER_ON_SEGFAULT`, which will instruct the compiler to automatically retry the final linker invocation if it looks like the linker segfaulted (up to 2 extra times). Unfortunately there have been no successful attempts to debug #38878. The only information seems to be that the linker (e.g. `ld` on OSX) is segfaulting somewhere in some thread pool implementation. This appears to be spurious as failed PRs will later merge. The hope is that this helps the queue keep moving without clogging and delaying PRs due to #38878.
2017-03-10 11:04:27 -06:00
RUSTC_RETRY_LINKER_ON_SEGFAULT=1
Attempt to debug sccache in more locations This should hopefully add support for debugging OSX and Windows presumed sccache failures instead of just the Linux ones.
2017-03-11 11:06:44 -06:00
SCCACHE_ERROR_LOG=/tmp/sccache.log
Target builds for older macOS
2017-03-13 13:36:44 -05:00
MACOSX_DEPLOYMENT_TARGET=10.8
MACOSX_STD_DEPLOYMENT_TARGET=10.7
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
os: osx
travis: Tweak OSX image configuration Somewhere between https://travis-ci.org/rust-lang/rust/jobs/192352185 and https://travis-ci.org/rust-lang/rust/jobs/192440181 it looks like our configuration for a newer OSX image was lost as LLDB has reverted itself back to 350. This fix appeared to work for the libc crate so let's see if we can configure it to work for the rust repo as well.
2017-01-16 20:43:38 -06:00
osx_image: xcode8.2
rustbuild: Add sccache support 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-12 13:36:52 -06:00
install: *osx_install_sccache
travis: Add builders without assertions This commit adds three new builders, one OSX, one Linux, and one MSVC, which will produce "nightlies" with LLVM assertions disabled. Currently all nightly releases have LLVM assertions enabled to catch bugs before they reach the beta/stable channels. The beta/stable channels, however, do not have LLVM assertions enabled. Unfortunately though projects like Servo are stuck on nightlies for the near future at least and are also suffering very long compile times. The purpose of this commit is to provide artifacts to these projects which are not distributed through normal channels (e.g. rustup) but are provided for developers to use locally if need be. Logistically these builds will all be uploaded to `rustc-builds-alt` instead of the `rustc-builds` folder of the `rust-lang-ci` bucket. These builds will stay there forever (until cleaned out if necessary) and there are no plans to integrate this with rustup and/or the official release process.
2017-02-11 19:28:29 -06:00
# "alternate" deployments, these are "nightlies" but don't have assertions
# turned on, they're deployed to a different location primarily for projects
# which are stuck on nightly and don't want llvm assertions in the artifacts
# that they use.
- env: IMAGE=dist-x86-linux DEPLOY_ALT=1
- env: >
RUST_CHECK_TARGET=dist
RUST_CONFIGURE_ARGS="--enable-extended"
SRC=.
DEPLOY_ALT=1
rustc: Support auto-retry linking on a segfault This is a last-ditch attempt to help our pain with dealing with #38878 on the bots. A new environment variable is added to the compiler, `RUSTC_RETRY_LINKER_ON_SEGFAULT`, which will instruct the compiler to automatically retry the final linker invocation if it looks like the linker segfaulted (up to 2 extra times). Unfortunately there have been no successful attempts to debug #38878. The only information seems to be that the linker (e.g. `ld` on OSX) is segfaulting somewhere in some thread pool implementation. This appears to be spurious as failed PRs will later merge. The hope is that this helps the queue keep moving without clogging and delaying PRs due to #38878.
2017-03-10 11:04:27 -06:00
RUSTC_RETRY_LINKER_ON_SEGFAULT=1
Attempt to debug sccache in more locations This should hopefully add support for debugging OSX and Windows presumed sccache failures instead of just the Linux ones.
2017-03-11 11:06:44 -06:00
SCCACHE_ERROR_LOG=/tmp/sccache.log
Target builds for older macOS
2017-03-13 13:36:44 -05:00
MACOSX_DEPLOYMENT_TARGET=10.8
MACOSX_STD_DEPLOYMENT_TARGET=10.7
travis: Add builders without assertions This commit adds three new builders, one OSX, one Linux, and one MSVC, which will produce "nightlies" with LLVM assertions disabled. Currently all nightly releases have LLVM assertions enabled to catch bugs before they reach the beta/stable channels. The beta/stable channels, however, do not have LLVM assertions enabled. Unfortunately though projects like Servo are stuck on nightlies for the near future at least and are also suffering very long compile times. The purpose of this commit is to provide artifacts to these projects which are not distributed through normal channels (e.g. rustup) but are provided for developers to use locally if need be. Logistically these builds will all be uploaded to `rustc-builds-alt` instead of the `rustc-builds` folder of the `rust-lang-ci` bucket. These builds will stay there forever (until cleaned out if necessary) and there are no plans to integrate this with rustup and/or the official release process.
2017-02-11 19:28:29 -06:00
os: osx
osx_image: xcode8.2
install: *osx_install_sccache
rustbuild: Add sccache support 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-12 13:36:52 -06:00
env:
global:
- SCCACHE_BUCKET=rust-lang-ci-sccache
- AWS_ACCESS_KEY_ID=AKIAIMX7VLAS3PZAVLUQ
# AWS_SECRET_ACCESS_KEY=...
- secure: "Pixhh0hXDqGCdOyLtGFjli3J2AtDWIpyb2btIrLe956nCBDRutRoMm6rv5DI9sFZN07Mms7VzNNvhc9wCW1y63JAm414d2Co7Ob8kWMZlz9l9t7ACHuktUiis8yr+S4Quq1Vqd6pqi7pf2J++UxC8R/uLeqVrubzr6+X7AbmEFE="
Use Travis trusty infrastructure
2015-10-18 20:37:14 -05:00
travis: Add timestamps to all build messages When debugging why builds are taking so long it's often useful to get the timestamp of all log messages as we're not always timing every tiny step of the build. I wrote a [utility] for prepending a relative timestamp from the start of a process which is now downloaded to the builders and is what we wrap the entire build invocation in. [utility]: https://github.com/alexcrichton/stamp-rs Closes #40577
2017-03-17 11:31:28 -05:00
# Note that this is overridden on OSX builders
install: >
travis: Don't enable quiet tests This makes travis problems more difficult to debug, so let's just enable more verbose logging.
2017-03-17 11:33:34 -05:00
travis_retry curl -o $HOME/stamp https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-03-17-stamp-x86_64-unknown-linux-musl &&
chmod +x $HOME/stamp &&
export PATH=$PATH:$HOME
travis: Add timestamps to all build messages When debugging why builds are taking so long it's often useful to get the timestamp of all log messages as we're not always timing every tiny step of the build. I wrote a [utility] for prepending a relative timestamp from the start of a process which is now downloaded to the builders and is what we wrap the entire build invocation in. [utility]: https://github.com/alexcrichton/stamp-rs Closes #40577
2017-03-17 11:31:28 -05:00
add some disk usage accounting Try to figure out why we are out of free space
2017-03-08 14:19:33 -06:00
before_script:
- >
echo "#### Disk usage before running script:";
df -h;
du . | sort -nr | head -n100
Tweak Travis to use GCE Travis CI has new infrastructure using the Google Compute Engine which has both faster CPUs and more memory, and we've been encouraged to switch as it should help our build times! The only downside currently, however, is that IPv6 is disabled, causing a number of standard library tests to fail. Consequently this commit tweaks our travis config in a few ways: * ccache is disabled as it's not working on GCE just yet * Docker is used to run tests inside which reportedly will get IPv6 working * A system LLVM installation is used instead of building LLVM itself. This is primarily done to reduce build times, but we want automation for this sort of behavior anyway and we can extend this in the future with building from source as well if needed. * gcc-specific logic is removed as the docker image for Ubuntu gives us a recent-enough gcc by default.
2015-09-18 12:19:23 -05:00
script:
mk: Switch rustbuild to the default build system 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-16 14:31:19 -06:00
- >
if [ "$ALLOW_PR" = "" ] && [ "$TRAVIS_BRANCH" != "auto" ]; then
echo skipping, not a full build;
elif [ "$TRAVIS_OS_NAME" = "osx" ]; then
travis: Add timestamps to all build messages When debugging why builds are taking so long it's often useful to get the timestamp of all log messages as we're not always timing every tiny step of the build. I wrote a [utility] for prepending a relative timestamp from the start of a process which is now downloaded to the builders and is what we wrap the entire build invocation in. [utility]: https://github.com/alexcrichton/stamp-rs Closes #40577
2017-03-17 11:31:28 -05:00
travis_retry stamp sh -c 'git submodule deinit -f . && git submodule update --init' &&
stamp src/ci/run.sh;
mk: Switch rustbuild to the default build system 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-16 14:31:19 -06:00
else
travis: Add timestamps to all build messages When debugging why builds are taking so long it's often useful to get the timestamp of all log messages as we're not always timing every tiny step of the build. I wrote a [utility] for prepending a relative timestamp from the start of a process which is now downloaded to the builders and is what we wrap the entire build invocation in. [utility]: https://github.com/alexcrichton/stamp-rs Closes #40577
2017-03-17 11:31:28 -05:00
travis_retry stamp sh -c 'git submodule deinit -f . && git submodule update --init' &&
stamp src/ci/docker/run.sh $IMAGE;
mk: Switch rustbuild to the default build system 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-16 14:31:19 -06:00
fi
travis: Use LLVM 3.4 instead of LLVM 3.3 This version is slightly more up to date and is closer to the 3.5 that we're using. This also updates the travis config to have a build matrix which tests rust against LLVM 3.3 and 3.4. For pull requests only LLVM 3.4 is tested to reduce the load on travis. This is mostly just fluff, there's no real reason to gate rust on these results, it's more of just a nice thing to know when we break compatibility with LLVM 3.3 and 3.4 (and eventually 3.5). This turns off notifications of failed commits (which are sent out for pushes to master).
2014-03-05 23:17:15 -06:00
add some disk usage accounting Try to figure out why we are out of free space
2017-03-08 14:19:33 -06:00
after_success:
- >
echo "#### Build successful; Disk usage after running script:";
df -h;
du . | sort -nr | head -n100
after_failure:
- >
echo "#### Build failed; Disk usage after running script:";
df -h;
du . | sort -nr | head -n100
travis: See if OSX generates crash dumps I know for a fact we've had sccache segfault on various platforms and we've also historically had a lot of problems with the linker on OSX. Let's just poke around in the crash log directory to see if anything exists. If in the future we see a build we think segfaulted *and* there's contents here then we can add some bits that actually print out the logs.
2017-03-23 14:00:50 -05:00
# One of these is the linux sccache log, one is the OSX sccache log. Instead
# of worrying about what system we are just cat both. One of these commands
# will fail but that's ok, they'll both get executed.
travis: Attempt to debug sccache failures I can't find anything that'd cause unexpected EOF in the source, so let's try taking a look at the error logs on failures.
2017-03-07 11:08:03 -06:00
- cat obj/tmp/sccache.log
Attempt to debug sccache in more locations This should hopefully add support for debugging OSX and Windows presumed sccache failures instead of just the Linux ones.
2017-03-11 11:06:44 -06:00
- cat /tmp/sccache.log
add some disk usage accounting Try to figure out why we are out of free space
2017-03-08 14:19:33 -06:00
travis: See if OSX generates crash dumps I know for a fact we've had sccache segfault on various platforms and we've also historically had a lot of problems with the linker on OSX. Let's just poke around in the crash log directory to see if anything exists. If in the future we see a build we think segfaulted *and* there's contents here then we can add some bits that actually print out the logs.
2017-03-23 14:00:50 -05:00
# Random attempt at debugging currently. Just poking around in here to see if
# anything shows up.
- ls $HOME/Library/Logs/DiagnosticReports/
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
# Save tagged docker images we created and load them if they're available
before_cache:
- docker history -q rust-ci |
grep -v missing |
xargs docker save |
travis: Don't use -9 on gzip I timed this locally and plain old `gzip` took 2m06s while `gzip -9` took a whopping 6m23s to save a mere 4MB out of 1.2GB. Let's shave a few minutes off the Android builder by turning down the compression level.
2016-12-25 23:56:07 -06:00
gzip > $HOME/docker/rust-ci.tar.gz
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
before_install:
- zcat $HOME/docker/rust-ci.tar.gz | docker load || true
point to buildbot Since 7b6ecc00
2015-06-11 04:26:19 -05:00
travis: Use LLVM 3.4 instead of LLVM 3.3 This version is slightly more up to date and is closer to the 3.5 that we're using. This also updates the travis config to have a build matrix which tests rust against LLVM 3.3 and 3.4. For pull requests only LLVM 3.4 is tested to reduce the load on travis. This is mostly just fluff, there's no real reason to gate rust on these results, it's more of just a nice thing to know when we break compatibility with LLVM 3.3 and 3.4 (and eventually 3.5). This turns off notifications of failed commits (which are sent out for pushes to master).
2014-03-05 23:17:15 -06:00
notifications:
email: false
Move all Linux/OSX CI infastructure to Travis 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.
2016-10-11 14:21:40 -05:00
cache:
directories:
- $HOME/docker
travis: Start uploading artifacts on commits This commit starts adding the infrastructure for uploading release artifacts from AppVeyor/Travis on each commit. The idea is that eventually we'll upload a full release to AppVeyor/Travis in accordance with plans [outlined earlier]. Right now this configures Travis/Appveyor to upload all tarballs in the `dist` directory, and various images are updated to actually produce tarballs in these directories. These are nowhere near ready to be actual release artifacts, but this should allow us to play around with it and test it out. Once this commit lands we should start seeing artifacts uploaded on each commit. [outlined earlier]: https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489
2016-12-31 19:42:40 -06:00
before_deploy:
- mkdir -p deploy/$TRAVIS_COMMIT
- >
if [ "$TRAVIS_OS_NAME" == "osx" ]; then
travis: Really delete the `doc` folder Got two location to look at, be sure to delete them both.
2017-01-30 17:21:32 -06:00
rm -rf build/dist/doc &&
travis: Tweak artifact uploads * Don't upload `*.wixpdb` files by accident * Don't upload `doc` dir by accident * Fix level of indirection on Travis
2017-01-28 12:24:42 -06:00
cp -r build/dist/* deploy/$TRAVIS_COMMIT;
travis: Start uploading artifacts on commits This commit starts adding the infrastructure for uploading release artifacts from AppVeyor/Travis on each commit. The idea is that eventually we'll upload a full release to AppVeyor/Travis in accordance with plans [outlined earlier]. Right now this configures Travis/Appveyor to upload all tarballs in the `dist` directory, and various images are updated to actually produce tarballs in these directories. These are nowhere near ready to be actual release artifacts, but this should allow us to play around with it and test it out. Once this commit lands we should start seeing artifacts uploaded on each commit. [outlined earlier]: https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489
2016-12-31 19:42:40 -06:00
else
travis: Really delete the `doc` folder Got two location to look at, be sure to delete them both.
2017-01-30 17:21:32 -06:00
rm -rf obj/build/dist/doc &&
travis: Tweak artifact uploads * Don't upload `*.wixpdb` files by accident * Don't upload `doc` dir by accident * Fix level of indirection on Travis
2017-01-28 12:24:42 -06:00
cp -r obj/build/dist/* deploy/$TRAVIS_COMMIT;
travis: Start uploading artifacts on commits This commit starts adding the infrastructure for uploading release artifacts from AppVeyor/Travis on each commit. The idea is that eventually we'll upload a full release to AppVeyor/Travis in accordance with plans [outlined earlier]. Right now this configures Travis/Appveyor to upload all tarballs in the `dist` directory, and various images are updated to actually produce tarballs in these directories. These are nowhere near ready to be actual release artifacts, but this should allow us to play around with it and test it out. Once this commit lands we should start seeing artifacts uploaded on each commit. [outlined earlier]: https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489
2016-12-31 19:42:40 -06:00
fi
deploy:
- provider: s3
bucket: rust-lang-ci
skip_cleanup: true
local_dir: deploy
upload_dir: rustc-builds
acl: public_read
region: us-east-1
access_key_id: AKIAIPQVNYF2T3DTYIWQ
secret_access_key:
secure: "FBqDqOTeIPMu6v/WYPf4CFSlh9rLRZGKVtpLa5KkyuOhXRTrnEzBduEtS8/FMIxdQImvurhSvxWvqRybMOi4qoVfjMqqpHAI7uBbidbrvAcJoHNsx6BgUNVCIoH6a0UsAjTUtm6/YPIpzbHoLZXPL0GrHPMk6Mu04qVSmcYNWn4="
on:
branch: auto
condition: $DEPLOY = 1
travis: Add builders without assertions This commit adds three new builders, one OSX, one Linux, and one MSVC, which will produce "nightlies" with LLVM assertions disabled. Currently all nightly releases have LLVM assertions enabled to catch bugs before they reach the beta/stable channels. The beta/stable channels, however, do not have LLVM assertions enabled. Unfortunately though projects like Servo are stuck on nightlies for the near future at least and are also suffering very long compile times. The purpose of this commit is to provide artifacts to these projects which are not distributed through normal channels (e.g. rustup) but are provided for developers to use locally if need be. Logistically these builds will all be uploaded to `rustc-builds-alt` instead of the `rustc-builds` folder of the `rust-lang-ci` bucket. These builds will stay there forever (until cleaned out if necessary) and there are no plans to integrate this with rustup and/or the official release process.
2017-02-11 19:28:29 -06:00
# this is the same as the above deployment provider except that it uploads to
# a slightly different directory and has a different trigger
- provider: s3
bucket: rust-lang-ci
skip_cleanup: true
local_dir: deploy
upload_dir: rustc-builds-alt
acl: public_read
region: us-east-1
access_key_id: AKIAIPQVNYF2T3DTYIWQ
secret_access_key:
secure: "FBqDqOTeIPMu6v/WYPf4CFSlh9rLRZGKVtpLa5KkyuOhXRTrnEzBduEtS8/FMIxdQImvurhSvxWvqRybMOi4qoVfjMqqpHAI7uBbidbrvAcJoHNsx6BgUNVCIoH6a0UsAjTUtm6/YPIpzbHoLZXPL0GrHPMk6Mu04qVSmcYNWn4="
on:
branch: auto
condition: $DEPLOY_ALT = 1
Reference in New Issue Copy Permalink