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

381 lines
13 KiB
YAML
Raw Normal View History

Change language in Travis configuration to shell In theory, this will give us more disk space to work with and unblock the queue.
2017-07-12 17:34:18 -05:00
language: shell
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
ci: Upgrade Travis to Xenial In theory we shouldn't require trusty so long as docker continues to work!
2018-12-18 15:32:09 -06:00
dist: xenial
Use Docker for Travis
2016-06-01 10:14:22 -05:00
services:
- docker
Enabled core dump on Linux, and print stack trace on failure.
2018-07-12 12:56:17 -05:00
addons:
apt:
packages:
- gdb
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:
Requires tools to test-pass if the corresponding submodule is updated. If a PR intends to update a tool but its test has failed, abort the merge regardless of current channel. This should help the tool maintainers if the update turns out to be failing due to changes in latest master.
2017-12-29 10:05:15 -06:00
depth: 2
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
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
env:
global:
- CI_JOB_NAME=$TRAVIS_JOB_NAME
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:
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
# Images used in testing PR and try-build should be run first.
Bump minimum required LLVM version to 6.0
2018-12-09 04:20:20 -06:00
- env: IMAGE=x86_64-gnu-llvm-6.0 RUST_BACKTRACE=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: x86_64-gnu-llvm-6.0
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: type = pull_request OR branch = auto
- env: IMAGE=dist-x86_64-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-x86_64-linux
Deploy builds both with asserts enabled and asserts disabled to CI. This also removes uploads to the 'try' bucket, and instead dumps everything into the two rustc-builds and rustc-builds-alt buckets. This makes lives easier, as there is only one location for a given "type" of build, and since we have the git commit hash in the filenames, this is fine; we won't run into uploads of the same commit.
2017-11-28 20:55:19 -06:00
if: branch = try OR branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
Update comment on alternate builds in .travis.yml https://github.com/rust-lang/rust/pull/45810#issuecomment-347257640
2017-11-28 07:26:59 -06:00
# "alternate" deployments, these are "nightlies" but have LLVM assertions
# turned on, they're deployed to a different location primarily for
# additional testing.
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
- env: IMAGE=dist-x86_64-linux DEPLOY_ALT=1
name: dist-x86_64-linux-alt
Make the try branch use alternate builds.
2017-11-07 00:31:06 -06:00
if: branch = try OR branch = auto
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: >
ci: Favor SCRIPT instead of RUST_CHECK_TARGET Since #61212 we've been timing out on OSX, and this looks to be because we're building tools like Cargo and the RLS twice instead of once. This turns out to be a slight bug in our configuration. CI builders using the `RUST_CHECK_TARGET` directive actually execute `make all` just before their acual target. In `make all` we're building a stage2 cargo, and then in `make dist` we're building a stage1 cargo. Other builders use `SCRIPT` which provides explicit control over what `x.py` script, for example, is used to execute the build. This moves almost all targets to using `SCRIPT` to ensure that we're explicitly specifying what's being built where. Additionally this updates the logic of `RUST_CHECK_TARGET` to remove the pre-flight tidy as well as the pre-flight `make all`. The system LLVM builder (run on PRs) now explicitly runs tidy first and then runs the rest of the test suite.
2019-05-30 09:22:53 -05:00
SCRIPT="./x.py dist"
Re-enable lldb Commit 7215963e56 disabled lldb due to the LLVM update. This patch updates lldb to build against the Rust LLVM, and re-enables it.
2018-11-27 14:06:49 -06:00
RUST_CONFIGURE_ARGS="--enable-extended --enable-profiler --enable-lldb --set rust.jemalloc"
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
SRC=.
DEPLOY_ALT=1
RUSTC_RETRY_LINKER_ON_SEGFAULT=1
MACOSX_DEPLOYMENT_TARGET=10.7
travis: Disable LLVM assertions on OSX Our OSX builders are routinely and significantly over hour 2 hour "soft limit" for testing PRs. I *think* that a big portion of this time comes from the fact that LLVM and debug assertions are enabled. In an effort to speed up these builders and reduce cycle time this commit disables LLVM assertions on OSX for all builders. My thinking is that we'll let this bake for a bit after merged to see what the effect is on timing on Travis. If it doesn't actually help much we can turn them back on, and if it doesn't help enough we can disable Rust debug assertions as well.
2017-09-15 12:34:05 -05:00
NO_LLVM_ASSERTIONS=1
ci: Disable rustc debug assertions on OSX This commit disables debug assertions for OSX in an effort to improve cycle time on OSX. It looks like #44610 didn't shave off quite as much time as desired so let's see how much this helps.
2017-09-16 19:25:12 -05:00
NO_DEBUG_ASSERTIONS=1
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
os: osx
travis: Upgrade dist builders for OSX This commit upgrades the dist builders for OSX to Travis's new `xcode9.3-moar` image which has 3 cores available to it instead of 2. This should help us provide speedier builds on OSX and hit timeouts less in theory! Note that historically the dist builders for OSX have been a different version than the ones that are running tests. I had forgotten why this was the case and digging around brought up 307615567 where apparently Xcode 8 wasn't able to compile LLVM with `MACOSX_DEPLOYMENT_TARGET=10.7` which we desired. On a whim I gave this PR a spin and it [looks like][green] this has since been fixed (maybe in LLVM?). In any case those green builds should hopefully mean that we can safely upgrade and get faster infrastructure to boot. This commit also includes an upgrade of OpenSSL. This is not done for security reasons but rather build system reasons. Originally builds with the new image [did not succeed][red] due to weird build failures in OpenSSL, but upgrading seems to have made the spurious errors go away to here's to also hoping that's fixed! [green]: https://travis-ci.org/rust-lang/rust/builds/351353412 [red]: https://travis-ci.org/rust-lang/rust/builds/350969248
2018-03-08 12:57:03 -06:00
osx_image: xcode9.3-moar
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-x86_64-apple-alt
Revert "Auto merge of #46360 - kennytm:workaround-travis-8821, r=kennytm" This reverts commit dc0e227745765c198958f0298785d18bcf61d4ae, reversing changes made to 77ab3a1d5ff69c0cb3eb85a75ef734eaf7429f1b. [skip ci]
2017-11-29 07:03:53 -06:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
# macOS builders. These are placed near the beginning because they are very
# slow to run.
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
travis: Compile OSX releases with Xcode 7 Unfortunately what we're using right now, Xcode 8.2, cannot compile LLVM for OSX 10.7. We've done this historically and Gecko would like to maintain this compabitiliby. This commit moves our release builders for OSX to using Xcode 7 which can compile LLVM for 10.7. The builders running tests continue to use Xcode 8.2, however, because the LLDB version with Xcode 7, 350, is blacklisted in running our LLDB tests. To continue running LLDB tests we'll stick with Xcode 8.2.
2017-03-31 13:04:25 -05:00
# OSX builders running tests, these run the full test suite.
inore some codegen tests when debug assertions are enabled
2018-08-06 11:45:15 -05:00
# NO_DEBUG_ASSERTIONS=1 to make them go faster, but also do have some
# runners that run `//ignore-debug` tests.
travis: Compile OSX releases with Xcode 7 Unfortunately what we're using right now, Xcode 8.2, cannot compile LLVM for OSX 10.7. We've done this historically and Gecko would like to maintain this compabitiliby. This commit moves our release builders for OSX to using Xcode 7 which can compile LLVM for 10.7. The builders running tests continue to use Xcode 8.2, however, because the LLDB version with Xcode 7, 350, is blacklisted in running our LLDB tests. To continue running LLDB tests we'll stick with Xcode 8.2.
2017-03-31 13:04:25 -05:00
#
# Note that the compiler is compiled to target 10.8 here because the Xcode
# version that we're using, 8.2, cannot compile LLVM for OSX 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
- env: >
ci: Favor SCRIPT instead of RUST_CHECK_TARGET Since #61212 we've been timing out on OSX, and this looks to be because we're building tools like Cargo and the RLS twice instead of once. This turns out to be a slight bug in our configuration. CI builders using the `RUST_CHECK_TARGET` directive actually execute `make all` just before their acual target. In `make all` we're building a stage2 cargo, and then in `make dist` we're building a stage1 cargo. Other builders use `SCRIPT` which provides explicit control over what `x.py` script, for example, is used to execute the build. This moves almost all targets to using `SCRIPT` to ensure that we're explicitly specifying what's being built where. Additionally this updates the logic of `RUST_CHECK_TARGET` to remove the pre-flight tidy as well as the pre-flight `make all`. The system LLVM builder (run on PRs) now explicitly runs tidy first and then runs the rest of the test suite.
2019-05-30 09:22:53 -05:00
SCRIPT="./x.py test"
Use `jemalloc-sys` on Linux and OSX compilers This commit adds opt-in support to the compiler to link to `jemalloc` in the compiler. When activated the compiler will depend on `jemalloc-sys`, instruct jemalloc to unprefix its symbols, and then link to it. The feature is activated by default on Linux/OSX compilers for x86_64/i686 platforms, and it's not enabled anywhere else for now. We may be able to opt-in other platforms in the future! Also note that the opt-in only happens on CI, it's otherwise unconditionally turned off by default. Closes #36963
2018-10-20 21:15:06 -05:00
RUST_CONFIGURE_ARGS="--build=x86_64-apple-darwin --enable-sanitizers --enable-profiler --set rust.jemalloc"
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
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: Disable LLVM assertions on OSX Our OSX builders are routinely and significantly over hour 2 hour "soft limit" for testing PRs. I *think* that a big portion of this time comes from the fact that LLVM and debug assertions are enabled. In an effort to speed up these builders and reduce cycle time this commit disables LLVM assertions on OSX for all builders. My thinking is that we'll let this bake for a bit after merged to see what the effect is on timing on Travis. If it doesn't actually help much we can turn them back on, and if it doesn't help enough we can disable Rust debug assertions as well.
2017-09-15 12:34:05 -05:00
NO_LLVM_ASSERTIONS=1
ci: Disable rustc debug assertions on OSX This commit disables debug assertions for OSX in an effort to improve cycle time on OSX. It looks like #44610 didn't shave off quite as much time as desired so let's see how much this helps.
2017-09-16 19:25:12 -05:00
NO_DEBUG_ASSERTIONS=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
os: osx
travis: Upgrade OSX builders This upgrades the OSX builders to the `xcode9.3-moar` image which has 3 cores as opposed to the 2 that our builders currently have. Should help make those OSX builds a bit speedier!
2018-03-06 16:37:08 -06:00
osx_image: xcode9.3-moar
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: x86_64-apple
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Automatically vendor Cargo deps when building the source tarballs.
2017-02-10 14:59:40 -06:00
- env: >
ci: Favor SCRIPT instead of RUST_CHECK_TARGET Since #61212 we've been timing out on OSX, and this looks to be because we're building tools like Cargo and the RLS twice instead of once. This turns out to be a slight bug in our configuration. CI builders using the `RUST_CHECK_TARGET` directive actually execute `make all` just before their acual target. In `make all` we're building a stage2 cargo, and then in `make dist` we're building a stage1 cargo. Other builders use `SCRIPT` which provides explicit control over what `x.py` script, for example, is used to execute the build. This moves almost all targets to using `SCRIPT` to ensure that we're explicitly specifying what's being built where. Additionally this updates the logic of `RUST_CHECK_TARGET` to remove the pre-flight tidy as well as the pre-flight `make all`. The system LLVM builder (run on PRs) now explicitly runs tidy first and then runs the rest of the test suite.
2019-05-30 09:22:53 -05:00
SCRIPT="./x.py test"
Use `jemalloc-sys` on Linux and OSX compilers This commit adds opt-in support to the compiler to link to `jemalloc` in the compiler. When activated the compiler will depend on `jemalloc-sys`, instruct jemalloc to unprefix its symbols, and then link to it. The feature is activated by default on Linux/OSX compilers for x86_64/i686 platforms, and it's not enabled anywhere else for now. We may be able to opt-in other platforms in the future! Also note that the opt-in only happens on CI, it's otherwise unconditionally turned off by default. Closes #36963
2018-10-20 21:15:06 -05:00
RUST_CONFIGURE_ARGS="--build=i686-apple-darwin --set rust.jemalloc"
Automatically vendor Cargo deps when building the source tarballs.
2017-02-10 14:59:40 -06: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
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: Disable LLVM assertions on OSX Our OSX builders are routinely and significantly over hour 2 hour "soft limit" for testing PRs. I *think* that a big portion of this time comes from the fact that LLVM and debug assertions are enabled. In an effort to speed up these builders and reduce cycle time this commit disables LLVM assertions on OSX for all builders. My thinking is that we'll let this bake for a bit after merged to see what the effect is on timing on Travis. If it doesn't actually help much we can turn them back on, and if it doesn't help enough we can disable Rust debug assertions as well.
2017-09-15 12:34:05 -05:00
NO_LLVM_ASSERTIONS=1
ci: Disable rustc debug assertions on OSX This commit disables debug assertions for OSX in an effort to improve cycle time on OSX. It looks like #44610 didn't shave off quite as much time as desired so let's see how much this helps.
2017-09-16 19:25:12 -05:00
NO_DEBUG_ASSERTIONS=1
Automatically vendor Cargo deps when building the source tarballs.
2017-02-10 14:59:40 -06:00
os: osx
travis: Upgrade OSX builders This upgrades the OSX builders to the `xcode9.3-moar` image which has 3 cores as opposed to the 2 that our builders currently have. Should help make those OSX builds a bit speedier!
2018-03-06 16:37:08 -06:00
osx_image: xcode9.3-moar
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: i686-apple
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
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
travis: Compile OSX releases with Xcode 7 Unfortunately what we're using right now, Xcode 8.2, cannot compile LLVM for OSX 10.7. We've done this historically and Gecko would like to maintain this compabitiliby. This commit moves our release builders for OSX to using Xcode 7 which can compile LLVM for 10.7. The builders running tests continue to use Xcode 8.2, however, because the LLDB version with Xcode 7, 350, is blacklisted in running our LLDB tests. To continue running LLDB tests we'll stick with Xcode 8.2.
2017-03-31 13:04:25 -05:00
# OSX builders producing releases. These do not run the full test suite and
# just produce a bunch of artifacts.
#
# Note that these are running in the `xcode7` image instead of the
# `xcode8.2` image as above. That's because we want to build releases for
# OSX 10.7 and `xcode7` is the latest Xcode able to compile LLVM for 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
- env: >
ci: Favor SCRIPT instead of RUST_CHECK_TARGET Since #61212 we've been timing out on OSX, and this looks to be because we're building tools like Cargo and the RLS twice instead of once. This turns out to be a slight bug in our configuration. CI builders using the `RUST_CHECK_TARGET` directive actually execute `make all` just before their acual target. In `make all` we're building a stage2 cargo, and then in `make dist` we're building a stage1 cargo. Other builders use `SCRIPT` which provides explicit control over what `x.py` script, for example, is used to execute the build. This moves almost all targets to using `SCRIPT` to ensure that we're explicitly specifying what's being built where. Additionally this updates the logic of `RUST_CHECK_TARGET` to remove the pre-flight tidy as well as the pre-flight `make all`. The system LLVM builder (run on PRs) now explicitly runs tidy first and then runs the rest of the test suite.
2019-05-30 09:22:53 -05:00
SCRIPT="./x.py dist"
Re-enable lldb Commit 7215963e56 disabled lldb due to the LLVM update. This patch updates lldb to build against the Rust LLVM, and re-enables it.
2018-11-27 14:06:49 -06:00
RUST_CONFIGURE_ARGS="--build=i686-apple-darwin --enable-full-tools --enable-profiler --enable-lldb --set rust.jemalloc"
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
travis: Compile OSX releases with Xcode 7 Unfortunately what we're using right now, Xcode 8.2, cannot compile LLVM for OSX 10.7. We've done this historically and Gecko would like to maintain this compabitiliby. This commit moves our release builders for OSX to using Xcode 7 which can compile LLVM for 10.7. The builders running tests continue to use Xcode 8.2, however, because the LLDB version with Xcode 7, 350, is blacklisted in running our LLDB tests. To continue running LLDB tests we'll stick with Xcode 8.2.
2017-03-31 13:04:25 -05:00
MACOSX_DEPLOYMENT_TARGET=10.7
travis: Disable LLVM assertions on OSX Our OSX builders are routinely and significantly over hour 2 hour "soft limit" for testing PRs. I *think* that a big portion of this time comes from the fact that LLVM and debug assertions are enabled. In an effort to speed up these builders and reduce cycle time this commit disables LLVM assertions on OSX for all builders. My thinking is that we'll let this bake for a bit after merged to see what the effect is on timing on Travis. If it doesn't actually help much we can turn them back on, and if it doesn't help enough we can disable Rust debug assertions as well.
2017-09-15 12:34:05 -05:00
NO_LLVM_ASSERTIONS=1
ci: Disable rustc debug assertions on OSX This commit disables debug assertions for OSX in an effort to improve cycle time on OSX. It looks like #44610 didn't shave off quite as much time as desired so let's see how much this helps.
2017-09-16 19:25:12 -05:00
NO_DEBUG_ASSERTIONS=1
Add DIST_REQUIRE_ALL_TOOLS to CI scripts
2018-09-28 02:07:44 -05:00
DIST_REQUIRE_ALL_TOOLS=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
os: osx
travis: Upgrade dist builders for OSX This commit upgrades the dist builders for OSX to Travis's new `xcode9.3-moar` image which has 3 cores available to it instead of 2. This should help us provide speedier builds on OSX and hit timeouts less in theory! Note that historically the dist builders for OSX have been a different version than the ones that are running tests. I had forgotten why this was the case and digging around brought up 307615567 where apparently Xcode 8 wasn't able to compile LLVM with `MACOSX_DEPLOYMENT_TARGET=10.7` which we desired. On a whim I gave this PR a spin and it [looks like][green] this has since been fixed (maybe in LLVM?). In any case those green builds should hopefully mean that we can safely upgrade and get faster infrastructure to boot. This commit also includes an upgrade of OpenSSL. This is not done for security reasons but rather build system reasons. Originally builds with the new image [did not succeed][red] due to weird build failures in OpenSSL, but upgrading seems to have made the spurious errors go away to here's to also hoping that's fixed! [green]: https://travis-ci.org/rust-lang/rust/builds/351353412 [red]: https://travis-ci.org/rust-lang/rust/builds/350969248
2018-03-08 12:57:03 -06:00
osx_image: xcode9.3-moar
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-i686-apple
Revert "Auto merge of #46360 - kennytm:workaround-travis-8821, r=kennytm" This reverts commit dc0e227745765c198958f0298785d18bcf61d4ae, reversing changes made to 77ab3a1d5ff69c0cb3eb85a75ef734eaf7429f1b. [skip ci]
2017-11-29 07:03:53 -06:00
if: branch = auto
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -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
- env: >
ci: Favor SCRIPT instead of RUST_CHECK_TARGET Since #61212 we've been timing out on OSX, and this looks to be because we're building tools like Cargo and the RLS twice instead of once. This turns out to be a slight bug in our configuration. CI builders using the `RUST_CHECK_TARGET` directive actually execute `make all` just before their acual target. In `make all` we're building a stage2 cargo, and then in `make dist` we're building a stage1 cargo. Other builders use `SCRIPT` which provides explicit control over what `x.py` script, for example, is used to execute the build. This moves almost all targets to using `SCRIPT` to ensure that we're explicitly specifying what's being built where. Additionally this updates the logic of `RUST_CHECK_TARGET` to remove the pre-flight tidy as well as the pre-flight `make all`. The system LLVM builder (run on PRs) now explicitly runs tidy first and then runs the rest of the test suite.
2019-05-30 09:22:53 -05:00
SCRIPT="./x.py dist"
Re-enable lldb Commit 7215963e56 disabled lldb due to the LLVM update. This patch updates lldb to build against the Rust LLVM, and re-enables it.
2018-11-27 14:06:49 -06:00
RUST_CONFIGURE_ARGS="--target=aarch64-apple-ios,armv7-apple-ios,armv7s-apple-ios,i386-apple-ios,x86_64-apple-ios --enable-full-tools --enable-sanitizers --enable-profiler --enable-lldb --set rust.jemalloc"
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
travis: Compile OSX releases with Xcode 7 Unfortunately what we're using right now, Xcode 8.2, cannot compile LLVM for OSX 10.7. We've done this historically and Gecko would like to maintain this compabitiliby. This commit moves our release builders for OSX to using Xcode 7 which can compile LLVM for 10.7. The builders running tests continue to use Xcode 8.2, however, because the LLDB version with Xcode 7, 350, is blacklisted in running our LLDB tests. To continue running LLDB tests we'll stick with Xcode 8.2.
2017-03-31 13:04:25 -05:00
MACOSX_DEPLOYMENT_TARGET=10.7
travis: Disable LLVM assertions on OSX Our OSX builders are routinely and significantly over hour 2 hour "soft limit" for testing PRs. I *think* that a big portion of this time comes from the fact that LLVM and debug assertions are enabled. In an effort to speed up these builders and reduce cycle time this commit disables LLVM assertions on OSX for all builders. My thinking is that we'll let this bake for a bit after merged to see what the effect is on timing on Travis. If it doesn't actually help much we can turn them back on, and if it doesn't help enough we can disable Rust debug assertions as well.
2017-09-15 12:34:05 -05:00
NO_LLVM_ASSERTIONS=1
ci: Disable rustc debug assertions on OSX This commit disables debug assertions for OSX in an effort to improve cycle time on OSX. It looks like #44610 didn't shave off quite as much time as desired so let's see how much this helps.
2017-09-16 19:25:12 -05:00
NO_DEBUG_ASSERTIONS=1
Add DIST_REQUIRE_ALL_TOOLS to CI scripts
2018-09-28 02:07:44 -05:00
DIST_REQUIRE_ALL_TOOLS=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
os: osx
travis: Upgrade dist builders for OSX This commit upgrades the dist builders for OSX to Travis's new `xcode9.3-moar` image which has 3 cores available to it instead of 2. This should help us provide speedier builds on OSX and hit timeouts less in theory! Note that historically the dist builders for OSX have been a different version than the ones that are running tests. I had forgotten why this was the case and digging around brought up 307615567 where apparently Xcode 8 wasn't able to compile LLVM with `MACOSX_DEPLOYMENT_TARGET=10.7` which we desired. On a whim I gave this PR a spin and it [looks like][green] this has since been fixed (maybe in LLVM?). In any case those green builds should hopefully mean that we can safely upgrade and get faster infrastructure to boot. This commit also includes an upgrade of OpenSSL. This is not done for security reasons but rather build system reasons. Originally builds with the new image [did not succeed][red] due to weird build failures in OpenSSL, but upgrading seems to have made the spurious errors go away to here's to also hoping that's fixed! [green]: https://travis-ci.org/rust-lang/rust/builds/351353412 [red]: https://travis-ci.org/rust-lang/rust/builds/350969248
2018-03-08 12:57:03 -06:00
osx_image: xcode9.3-moar
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-x86_64-apple
Revert "Auto merge of #46360 - kennytm:workaround-travis-8821, r=kennytm" This reverts commit dc0e227745765c198958f0298785d18bcf61d4ae, reversing changes made to 77ab3a1d5ff69c0cb3eb85a75ef734eaf7429f1b. [skip ci]
2017-11-29 07:03:53 -06:00
if: branch = auto
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
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
# Linux builders, remaining docker images
- env: IMAGE=arm-android
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: arm-android
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=armhf-gnu
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: armhf-gnu
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Rename cross(2) builder to dist-various-{1,2} Follows the convention of the other builders.
2017-12-04 12:38:19 -06:00
- env: IMAGE=dist-various-1 DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-various-1
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Rename cross(2) builder to dist-various-{1,2} Follows the convention of the other builders.
2017-12-04 12:38:19 -06:00
- env: IMAGE=dist-various-2 DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-various-2
restore 'if: branch = auto' for cross2 builder
2017-10-05 13:42:27 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-aarch64-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-aarch64-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-android DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-android
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-arm-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-arm-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-armhf-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-armhf-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-armv7-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-armv7-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Add i586-unknown-linux-musl target
2018-01-04 10:55:04 -06:00
- env: IMAGE=dist-i586-gnu-i586-i686-musl DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-i586-gnu-i586-i686-musl
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-i686-freebsd DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-i686-freebsd
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-i686-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-i686-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-mips-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-mips-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-mips64-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-mips64-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-mips64el-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-mips64el-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-mipsel-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-mipsel-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-powerpc-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-powerpc-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-powerpc64-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-powerpc64-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-powerpc64le-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-powerpc64le-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-s390x-linux DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-s390x-linux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-x86_64-freebsd DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-x86_64-freebsd
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-x86_64-musl DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-x86_64-musl
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=dist-x86_64-netbsd DEPLOY=1
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: dist-x86_64-netbsd
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=asmjs
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: asmjs
revert travis-ci changes
2018-07-09 10:25:00 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=i686-gnu
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: i686-gnu
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=i686-gnu-nopt
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: i686-gnu-nopt
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Use correct CI test image for WASM and NVPTX
2019-01-29 14:00:07 -06:00
- env: IMAGE=test-various
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: test-various
revert travis-ci changes
2018-07-09 10:25:00 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=x86_64-gnu
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: x86_64-gnu
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=x86_64-gnu-full-bootstrap
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: x86_64-gnu-full-bootstrap
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=x86_64-gnu-aux
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: x86_64-gnu-aux
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Move the swap the tools test and cargotest within check-aux. The cargotest job is renamed to tools for clarification.
2017-11-28 09:19:54 -06:00
- env: IMAGE=x86_64-gnu-tools
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: x86_64-gnu-tools
Run x86_64-gnu-tools job for "update cargo" PRs since cargo can break RLS.
2018-12-03 01:09:47 -06:00
if: branch = auto OR (type = pull_request AND commit_message =~ /(?i:^update.*\b(rls|rustfmt|clippy|miri|cargo)\b)/)
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=x86_64-gnu-debug
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: x86_64-gnu-debug
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=x86_64-gnu-nopt
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: x86_64-gnu-nopt
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- env: IMAGE=x86_64-gnu-distcheck
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: x86_64-gnu-distcheck
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
if: branch = auto
Add check builder for Windows to Travis
2018-04-11 10:46:58 -05:00
- env: IMAGE=mingw-check
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
name: mingw-check
Add check builder for Windows to Travis
2018-04-11 10:46:58 -05:00
if: type = pull_request OR branch = auto
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
Upload the toolstate to the remote repository.
2017-12-04 08:31:57 -06:00
- stage: publish toolstate
if: branch = master AND type = push
before_install: []
install: []
sudo: false
script:
MESSAGE_FILE=$(mktemp -t msg.XXXXXX);
. src/ci/docker/x86_64-gnu-tools/repo.sh;
Submit a comment to the PR in additional to pushing a commit. Fix rust-lang-nursery/rust-toolstate#2.
2018-02-21 08:58:06 -06:00
commit_toolstate_change "$MESSAGE_FILE" "$TRAVIS_BUILD_DIR/src/tools/publish_toolstate.py" "$(git rev-parse HEAD)" "$(git log --format=%s -n1 HEAD)" "$MESSAGE_FILE" "$TOOLSTATE_REPO_ACCESS_TOKEN";
Upload the toolstate to the remote repository.
2017-12-04 08:31:57 -06:00
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
before_install:
ci: Move global credentials to web configuration This commit moves a number of our encrypted credentials stored in configuration files in this repository to env vars on the web UI. This will hopefully make it easier to rotate credentials in the future as well as quickly change them if the need arises. (quicker than landing a PR that is). This also updates the travis deployment process to always use the `aws` command line tool which we're already installing on Linux and should enable us to avoid all `dpl` gem issues as well as have greater control over what's going where.
2018-10-24 04:29:53 -05:00
# We'll use the AWS cli to download/upload cached docker layers as well as
# push our deployments, so download that here.
Make sure the installed `awscli` is found on macOS.
2018-11-01 02:30:30 -05:00
- pip install --user awscli; export PATH=$PATH:$HOME/.local/bin:$HOME/Library/Python/2.7/bin/
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
- mkdir -p $HOME/rustsrc
Enable IPv6 support in Dockers to workaround travis-ci/travis-ci#8891.
2017-12-21 13:14:21 -06:00
# FIXME(#46924): these two commands are required to enable IPv6,
# they shouldn't exist, please revert once more official solutions appeared.
# see https://github.com/travis-ci/travis-ci/issues/8891#issuecomment-353403729
- if [ "$TRAVIS_OS_NAME" = linux ]; then
Follow up to #46924 It seems using `fe80::/64` causes `docker start` to fail with "Address already in use". Try to change to a unique local address range instead.
2017-12-25 12:36:17 -06:00
echo '{"ipv6":true,"fixed-cidr-v6":"fd9a:8454:6789:13f7::/64"}' | sudo tee /etc/docker/daemon.json;
Enable IPv6 support in Dockers to workaround travis-ci/travis-ci#8891.
2017-12-21 13:14:21 -06:00
sudo service docker restart;
fi
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
install:
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
- case "$TRAVIS_OS_NAME" in
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
linux)
ci: Upload/download from a new S3 bucket Moving buckets from us-east-1 to us-west-1 because us-west-1 is where rust-central-station itself runs and in general is where we have all our other buckets.
2017-09-15 18:04:13 -05:00
travis_retry curl -fo $HOME/stamp https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/2017-03-17-stamp-x86_64-unknown-linux-musl &&
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
chmod +x $HOME/stamp &&
export PATH=$PATH:$HOME
;;
osx)
ci: Favor SCRIPT instead of RUST_CHECK_TARGET Since #61212 we've been timing out on OSX, and this looks to be because we're building tools like Cargo and the RLS twice instead of once. This turns out to be a slight bug in our configuration. CI builders using the `RUST_CHECK_TARGET` directive actually execute `make all` just before their acual target. In `make all` we're building a stage2 cargo, and then in `make dist` we're building a stage1 cargo. Other builders use `SCRIPT` which provides explicit control over what `x.py` script, for example, is used to execute the build. This moves almost all targets to using `SCRIPT` to ensure that we're explicitly specifying what's being built where. Additionally this updates the logic of `RUST_CHECK_TARGET` to remove the pre-flight tidy as well as the pre-flight `make all`. The system LLVM builder (run on PRs) now explicitly runs tidy first and then runs the rest of the test suite.
2019-05-30 09:22:53 -05:00
if [[ "$SCRIPT" == "./x.py dist" ]]; then
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
travis_retry brew update &&
Add lldb to the build This optionally adds lldb (and clang, which it needs) to the build. Because rust uses LLVM 7, and because clang 7 is not yet released, a recent git master version of clang is used. The lldb that is used includes the Rust plugin. lldb is only built when asked for, or when doing a nightly build on macOS. Only macOS is done for now due to difficulties with the Python dependency.
2018-07-03 13:24:24 -05:00
travis_retry brew install xz &&
fix syntax
2019-06-15 06:17:42 -05:00
travis_retry brew install swig@3 &&
brew link --force swig@3;
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
fi &&
Update sccache to its master branch Ideally I'd like to soon enable sccache for rustbuild itself and some of the stage0 tools, but for that to work we'll need some better Rust support than the pretty old version we were previously using!
2018-03-01 16:50:50 -06:00
travis_retry curl -fo /usr/local/bin/sccache https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/2018-04-02-sccache-x86_64-apple-darwin &&
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
chmod +x /usr/local/bin/sccache &&
ci: Upload/download from a new S3 bucket Moving buckets from us-east-1 to us-west-1 because us-west-1 is where rust-central-station itself runs and in general is where we have all our other buckets.
2017-09-15 18:04:13 -05:00
travis_retry curl -fo /usr/local/bin/stamp https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/2017-03-17-stamp-x86_64-apple-darwin &&
ci: Compile LLVM with Clang 6.0.0 Currently on CI we predominately compile LLVM with the default system compiler which means gcc on Linux, some version of Clang on OSX, MSVC on Windows, and gcc on MinGW. This commit switches Linux, OSX, and Windows to all use Clang 6.0.0 to build LLVM (aka the C/C++ compiler as part of the bootstrap). This looks to generate faster code according to #49879 which translates to a faster rustc (as LLVM internally is faster) The major changes here were to the containers that build Linux releases, basically adding a new step that uses the previous gcc 4.8 compiler to compile the next Clang 6.0.0 compiler. Otherwise the OSX and Windows scripts have been updated to download precompiled versions of Clang 6 and configure the build to use them. Note that `cc` was updated here to fix using `clang-cl` with `cc-rs` on MSVC, as well as an update to `sccache` on Windows which was needed to correctly work with `clang-cl`. Finally the MinGW compiler is entirely left out here intentionally as it's currently thought that Clang can't generate C++ code for MinGW and we need to use gcc, but this should be verified eventually.
2018-04-24 10:34:14 -05:00
chmod +x /usr/local/bin/stamp &&
Update CI-clang to 7.0.0 for macOS dists.
2018-11-14 10:42:53 -06:00
travis_retry curl -f http://releases.llvm.org/7.0.0/clang+llvm-7.0.0-x86_64-apple-darwin.tar.xz | tar xJf - &&
export CC=`pwd`/clang+llvm-7.0.0-x86_64-apple-darwin/bin/clang &&
export CXX=`pwd`/clang+llvm-7.0.0-x86_64-apple-darwin/bin/clang++ &&
ci: Compile LLVM with Clang 6.0.0 Currently on CI we predominately compile LLVM with the default system compiler which means gcc on Linux, some version of Clang on OSX, MSVC on Windows, and gcc on MinGW. This commit switches Linux, OSX, and Windows to all use Clang 6.0.0 to build LLVM (aka the C/C++ compiler as part of the bootstrap). This looks to generate faster code according to #49879 which translates to a faster rustc (as LLVM internally is faster) The major changes here were to the containers that build Linux releases, basically adding a new step that uses the previous gcc 4.8 compiler to compile the next Clang 6.0.0 compiler. Otherwise the OSX and Windows scripts have been updated to download precompiled versions of Clang 6 and configure the build to use them. Note that `cc` was updated here to fix using `clang-cl` with `cc-rs` on MSVC, as well as an update to `sccache` on Windows which was needed to correctly work with `clang-cl`. Finally the MinGW compiler is entirely left out here intentionally as it's currently thought that Clang can't generate C++ code for MinGW and we need to use gcc, but this should be verified eventually.
2018-04-24 10:34:14 -05:00
export AR=ar
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
;;
Make use of Travis's conditional jobs.
2017-09-16 06:28:08 -05:00
esac
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
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
- >
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
RUN_SCRIPT="src/ci/init_repo.sh . $HOME/rustsrc";
if [ "$TRAVIS_OS_NAME" = "osx" ]; then
export RUN_SCRIPT="$RUN_SCRIPT && src/ci/run.sh";
Don't run travis tests on master. This saves us builders for more helpful purposes.
2017-06-03 13:49:03 -05:00
else
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
2017-07-15 11:10:26 -05:00
export RUN_SCRIPT="$RUN_SCRIPT && src/ci/docker/run.sh $IMAGE";
Enabled core dump on Linux, and print stack trace on failure.
2018-07-12 12:56:17 -05:00
# Enable core dump on Linux.
sudo sh -c 'echo "/checkout/obj/cores/core.%p.%E" > /proc/sys/kernel/core_pattern';
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
Added a job to dry-run the publish_toolstate.py once
2018-12-15 09:44:46 -06:00
- >
if [ "$IMAGE" = mingw-check ]; then
# verify the publish_toolstate script works.
git clone --depth=1 https://github.com/rust-lang-nursery/rust-toolstate.git;
cd rust-toolstate;
python2.7 "$TRAVIS_BUILD_DIR/src/tools/publish_toolstate.py" "$(git rev-parse HEAD)" "$(git log --format=%s -n1 HEAD)" "" "";
cd ..;
rm -rf rust-toolstate;
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
Record some details to help with possible bad clocks
2017-06-28 17:05:29 -05:00
# Log time information from this machine and an external machine for insight into possible
# clock drift. Timezones don't matter since relative deltas give all the necessary info.
ci: Improve log output (mainly Travis). * Bring back colors on Travis, which was disabled since #39036. Append --color=always to cargo when running in CI environment. * Removed `set -x` in the shell scripts. The `retry` function already prints which command it is running, add `-x` just add noise to the output. * Support travis_fold/travis_time. Matching pairs of these allow Travis CI to collapse the output in between. This greatly cut down the unnecessary "successful" output one need to scroll through before finding the failed statement.
2017-05-17 11:33:20 -05:00
script:
Record some details to help with possible bad clocks
2017-06-28 17:05:29 -05:00
- >
travis: Make a few `curl` invocations more resilient Use the `-f` flag to indicate that, for example, a 500 response code is to be considered a failure, triggering the normal retry logic. Also ignore errors where we check the date from google.com, as a failure there shouldn't fail the build.
2017-07-17 12:55:27 -05:00
date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Stamp the whole build script
2017-06-28 16:54:05 -05:00
- stamp sh -x -c "$RUN_SCRIPT"
Record some details to help with possible bad clocks
2017-06-28 17:05:29 -05:00
- >
travis: Make a few `curl` invocations more resilient Use the `-f` flag to indicate that, for example, a 500 response code is to be considered a failure, triggering the normal retry logic. Also ignore errors where we check the date from google.com, as a failure there shouldn't fail the build.
2017-07-17 12:55:27 -05:00
date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
ci: Improve log output (mainly Travis). * Bring back colors on Travis, which was disabled since #39036. Append --color=always to cargo when running in CI environment. * Removed `set -x` in the shell scripts. The `retry` function already prints which command it is running, add `-x` just add noise to the output. * Support travis_fold/travis_time. Matching pairs of these allow Travis CI to collapse the output in between. This greatly cut down the unnecessary "successful" output one need to scroll through before finding the failed statement.
2017-05-17 11:33:20 -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
after_success:
- >
echo "#### Build successful; Disk usage after running script:";
df -h;
du . | sort -nr | head -n100
ci: Move global credentials to web configuration This commit moves a number of our encrypted credentials stored in configuration files in this repository to env vars on the web UI. This will hopefully make it easier to rotate credentials in the future as well as quickly change them if the need arises. (quicker than landing a PR that is). This also updates the travis deployment process to always use the `aws` command line tool which we're already installing on Linux and should enable us to avoid all `dpl` gem issues as well as have greater control over what's going where.
2018-10-24 04:29:53 -05:00
- >
if [ "$DEPLOY$DEPLOY_ALT" == "1" ]; then
mkdir -p deploy/$TRAVIS_COMMIT;
if [ "$TRAVIS_OS_NAME" == "osx" ]; then
rm -rf build/dist/doc &&
cp -r build/dist/* deploy/$TRAVIS_COMMIT;
else
rm -rf obj/build/dist/doc &&
cp -r obj/build/dist/* deploy/$TRAVIS_COMMIT;
fi;
ls -la deploy/$TRAVIS_COMMIT;
deploy_dir=rustc-builds;
if [ "$DEPLOY_ALT" == "1" ]; then
deploy_dir=rustc-builds-alt;
fi;
travis_retry aws s3 cp --no-progress --recursive --acl public-read ./deploy s3://rust-lang-ci2/$deploy_dir
fi
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_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
# Random attempt at debugging currently. Just poking around in here to see if
# anything shows up.
Enabled core dump on Linux, and print stack trace on failure.
2018-07-12 12:56:17 -05:00
# Dump backtrace for macOS
Try to print the crash logs on macOS on failure. An attempt to debug #45230.
2017-11-05 11:10:09 -06:00
- ls -lat $HOME/Library/Logs/DiagnosticReports/
Travis/macOS: Improve crash log collection accuracy.
2017-11-15 10:54:39 -06:00
- find $HOME/Library/Logs/DiagnosticReports
-type f
Prevents the crash log printer on macOS from crashing the entire job.
2018-03-10 04:38:27 -06:00
-name '*.crash'
Travis/macOS: Improve crash log collection accuracy.
2017-11-15 10:54:39 -06:00
-not -name '*.stage2-*.crash'
-not -name 'com.apple.CoreSimulator.CoreSimulatorService-*.crash'
-exec printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" {} \;
Try to print the crash logs on macOS on failure. An attempt to debug #45230.
2017-11-05 11:10:09 -06:00
-exec head -750 {} \;
Prevents the crash log printer on macOS from crashing the entire job.
2018-03-10 04:38:27 -06:00
-exec echo travis_fold":"end:crashlog \; || true
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
Enabled core dump on Linux, and print stack trace on failure.
2018-07-12 12:56:17 -05:00
# Dump backtrace for Linux
- ln -s . checkout &&
for CORE in obj/cores/core.*; do
EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|');
if [ -f "$EXE" ]; then
printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE";
Pass --batch to gdb In one of my travis builds, I was surprised to find that the gdb pager was in use and caused travis to time out. Adding `--batch` to the gdb invocation will disable the pager. Note that the `-ex q` is retained, to make sure gdb exits with status 0, just in case `set -e` is in effect somehow.
2018-09-19 10:46:22 -05:00
gdb --batch -q -c "$CORE" "$EXE"
Enabled core dump on Linux, and print stack trace on failure.
2018-07-12 12:56:17 -05:00
-iex 'set auto-load off'
-iex 'dir src/'
-iex 'set sysroot .'
-ex bt
-ex q;
echo travis_fold":"end:crashlog;
fi;
done || true
Log the clang_rt.asan-dynamic-i386.vers on failure to track #50887
2018-06-09 12:31:55 -05:00
# see #50887
Enabled core dump on Linux, and print stack trace on failure.
2018-07-12 12:56:17 -05:00
- cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
Log the clang_rt.asan-dynamic-i386.vers on failure to track #50887
2018-06-09 12:31:55 -05:00
travis: Attempt to see if oom kills anything There's a suspicion that the OOM killer is killing sccache (maybe) so this adds some logging to test out that assumption to see if anything dies and is logged by `dmesg`
2017-03-23 14:33:24 -05:00
# attempt to debug anything killed by the oom killer on linux, just to see if
# it happened
- dmesg | grep -i kill
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
Reference in New Issue Copy Permalink