OpenE2K/rust
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
fa459a08e1
rust/appveyor.yml

276 lines
11 KiB
YAML
Raw Normal View History

Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
environment:
appveyor: Use VS2017 for all our images Originally added in #55935 to test build times, this was reverted in #56201 due to a belief that it caused the exit code 259 spurious errors. We've since learned, however, that the 259 exit code is likely not related to this image update as we're getting it in a number of locations now. VS2017 looks like it may be required to compile LLVm in the near future, notably discovered by #58408 where we attempted to update LLVM.
2018-11-13 22:42:05 +01:00
# This is required for at least an AArch64 compiler in one image, and is also
# going to soon be required for compiling LLVM.
APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017 Preview
Attempt to fix appveyor
2017-07-19 14:57:56 +02:00
# By default schannel checks revocation of certificates unlike some other SSL
# backends, but we've historically had problems on CI where a revocation
# server goes down presumably. See #43333 for more info
CARGO_HTTP_CHECK_REVOKE: false
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
matrix:
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
# 32/64 bit MSVC tests
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-10 00:48:58 +01:00
- CI_JOB_NAME: x86_64-msvc
MSYS_BITS: 64
Enable profiler selectively on some builders
2017-06-06 19:09:33 +02:00
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --enable-profiler
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
SCRIPT: python x.py test
ci: Disable llvm/debug assertions on x86_64-mingw Tracked at #59637 for re-enabling this commit disables assertions to hopefully bring the runtime for this builder under control.
2019-04-02 20:02:44 +02:00
# FIXME(#59637)
NO_DEBUG_ASSERTIONS: 1
NO_LLVM_ASSERTIONS: 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-10 00:48:58 +01:00
- CI_JOB_NAME: i686-msvc-1
MSYS_BITS: 32
appveyor: Shard more slow MSVC builders Take two more slow builders and split them in two to get them under 2 hrs
2018-03-07 04:19:56 +01:00
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-msvc
Add Azure Pipelines
2019-05-06 20:15:52 +02:00
SCRIPT: make ci-subset-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-10 00:48:58 +01:00
- CI_JOB_NAME: i686-msvc-2
MSYS_BITS: 32
appveyor: Shard more slow MSVC builders Take two more slow builders and split them in two to get them under 2 hrs
2018-03-07 04:19:56 +01:00
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-msvc
Add Azure Pipelines
2019-05-06 20:15:52 +02:00
SCRIPT: make ci-subset-2
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
# MSVC aux tests
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-10 00:48:58 +01:00
- CI_JOB_NAME: x86_64-msvc-aux
MSYS_BITS: 64
Fix an error in the appveyor config
2018-03-07 22:57:17 +01:00
RUST_CHECK_TARGET: check-aux EXCLUDE_CARGO=1
appveyor: Shard more slow MSVC builders Take two more slow builders and split them in two to get them under 2 hrs
2018-03-07 04:19:56 +01:00
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc
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-10 00:48:58 +01:00
- CI_JOB_NAME: x86_64-msvc-cargo
MSYS_BITS: 64
appveyor: Shard more slow MSVC builders Take two more slow builders and split them in two to get them under 2 hrs
2018-03-07 04:19:56 +01:00
SCRIPT: python x.py test src/tools/cargotest src/tools/cargo
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 21:31:19 +01:00
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
Move the swap the tools test and cargotest within check-aux. The cargotest job is renamed to tools for clarification.
2017-11-28 16:19:54 +01:00
# MSVC tools tests
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-10 00:48:58 +01:00
- CI_JOB_NAME: x86_64-msvc-tools
MSYS_BITS: 64
Upload the toolstate to the remote repository.
2017-12-04 15:31:57 +01:00
SCRIPT: src/ci/docker/x86_64-gnu-tools/checktools.sh x.py /tmp/toolstates.json windows
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --save-toolstates=/tmp/toolstates.json --enable-test-miri
Move cargotest to separate jobs on Travis-CI and AppVeyor
2017-09-15 20:31:48 +02:00
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
# 32/64-bit MinGW builds.
#
FIN: update appveyor mingw description
2017-04-14 11:27:35 +02:00
# We are using MinGW with posix threads since LLVM does not compile with
# the win32 threads version due to missing support for C++'s std::thread.
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
#
FIN: update appveyor mingw description
2017-04-14 11:27:35 +02:00
# Instead of relying on the MinGW version installed on appveryor we download
# and install one ourselves so we won't be surprised by changes to appveyor's
# build image.
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
#
# Finally, note that the downloads below are all in the `rust-lang-ci` S3
# bucket, but they cleraly didn't originate there! The downloads originally
# came from the mingw-w64 SourceForge download site. Unfortunately
# SourceForge is notoriously flaky, so we mirror it on our own infrastructure.
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-10 00:48:58 +01:00
- CI_JOB_NAME: i686-mingw-1
MSYS_BITS: 32
appveyor: Use Ninja/sccache on MSVC Now that the final bug fixes have been merged into sccache we can start leveraging sccache on the MSVC builders on AppVeyor instead of relying on the ad-hoc caching strategy of trigger files and whatnot.
2017-02-25 18:53:46 +01:00
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu
Add Azure Pipelines
2019-05-06 20:15:52 +02:00
SCRIPT: make ci-subset-1
Split MinGW tests into two builders on AppVeyor Run-pass and compile-fail tests appear to take the most significant chunk of time, so split them into their own builder.
2018-02-24 00:19:17 +01:00
MINGW_URL: https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror
MINGW_ARCHIVE: i686-6.3.0-release-posix-dwarf-rt_v5-rev2.7z
MINGW_DIR: mingw32
ci: Disable llvm/debug assertions on x86_64-mingw Tracked at #59637 for re-enabling this commit disables assertions to hopefully bring the runtime for this builder under control.
2019-04-02 20:02:44 +02:00
# FIXME(#59637)
NO_DEBUG_ASSERTIONS: 1
NO_LLVM_ASSERTIONS: 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-10 00:48:58 +01:00
- CI_JOB_NAME: i686-mingw-2
MSYS_BITS: 32
Split MinGW tests into two builders on AppVeyor Run-pass and compile-fail tests appear to take the most significant chunk of time, so split them into their own builder.
2018-02-24 00:19:17 +01:00
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu
Add Azure Pipelines
2019-05-06 20:15:52 +02:00
SCRIPT: make ci-subset-2
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-16 01:04:13 +02:00
MINGW_URL: https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror
appveyor: Upgrade to gcc for mingw 6.3.0 This commit sort of brings back #40777 by upgrading back to 6.3.0. While investigating #40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for #40184 contained in #40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes #40546
2017-04-20 17:35:03 +02:00
MINGW_ARCHIVE: i686-6.3.0-release-posix-dwarf-rt_v5-rev2.7z
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
MINGW_DIR: mingw32
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-10 00:48:58 +01:00
- CI_JOB_NAME: x86_64-mingw
MSYS_BITS: 64
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
SCRIPT: python x.py test
appveyor: Use Ninja/sccache on MSVC Now that the final bug fixes have been merged into sccache we can start leveraging sccache on the MSVC builders on AppVeyor instead of relying on the ad-hoc caching strategy of trigger files and whatnot.
2017-02-25 18:53:46 +01:00
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu
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-16 01:04:13 +02:00
MINGW_URL: https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror
appveyor: Upgrade to gcc for mingw 6.3.0 This commit sort of brings back #40777 by upgrading back to 6.3.0. While investigating #40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for #40184 contained in #40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes #40546
2017-04-20 17:35:03 +02:00
MINGW_ARCHIVE: x86_64-6.3.0-release-posix-seh-rt_v5-rev2.7z
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
MINGW_DIR: mingw64
ci: Disable llvm/debug assertions on x86_64-mingw Tracked at #59637 for re-enabling this commit disables assertions to hopefully bring the runtime for this builder under control.
2019-04-02 20:02:44 +02:00
# FIXME(#59637)
NO_DEBUG_ASSERTIONS: 1
NO_LLVM_ASSERTIONS: 1
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
# 32/64 bit MSVC and GNU deployment
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-10 00:48:58 +01:00
- CI_JOB_NAME: dist-x86_64-msvc
RUST_CONFIGURE_ARGS: >
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
--build=x86_64-pc-windows-msvc
add an appveyor config for aarch64-pc-windows-msvc Fixes #53864.
2018-10-01 16:20:12 +02:00
--target=x86_64-pc-windows-msvc,aarch64-pc-windows-msvc
rust: Import LLD for linking wasm objects This commit imports the LLD project from LLVM to serve as the default linker for the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently removed along with "binaryen linker" support in rustc. Moving to LLD brings with it a number of benefits for wasm code: * LLD is itself an actual linker, so there's no need to compile all wasm code with LTO any more. As a result builds should be *much* speedier as LTO is no longer forcibly enabled for all builds of the wasm target. * LLD is quickly becoming an "official solution" for linking wasm code together. This, I believe at least, is intended to be the main supported linker for native code and wasm moving forward. Picking up support early on should help ensure that we can help LLD identify bugs and otherwise prove that it works great for all our use cases! * Improvements to the wasm toolchain are currently primarily focused around LLVM and LLD (from what I can tell at least), so it's in general much better to be on this bandwagon for bugfixes and new features. * Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which means a postprocessor is no longer needed to show off Rust's "small wasm binary size". LLD is added in a pretty standard way to rustc right now. A new rustbuild target was defined for building LLD, and this is executed when a compiler's sysroot is being assembled. LLD is compiled against the LLVM that we've got in tree, which means we're currently on the `release_60` branch, but this may get upgraded in the near future! LLD is placed into rustc's sysroot in a `bin` directory. This is similar to where `gcc.exe` can be found on Windows. This directory is automatically added to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd` linker which implements the interface that `wasm-ld`, LLD's frontend, expects. Like Emscripten the LLD target is currently only enabled for Tier 1 platforms, notably OSX/Windows/Linux, and will need to be installed manually for compiling to wasm on other platforms. LLD is by default turned off in rustbuild, and requires a `config.toml` option to be enabled to turn it on. Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD has a native option for controlling this. [gc]: https://reviews.llvm.org/D42511
2017-08-27 03:30:12 +02:00
--enable-full-tools
Enable profiler selectively on some builders
2017-06-06 19:09:33 +02:00
--enable-profiler
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
SCRIPT: python x.py dist
Add DIST_REQUIRE_ALL_TOOLS to CI scripts
2018-09-28 09:07:44 +02:00
DIST_REQUIRE_ALL_TOOLS: 1
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
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-10 00:48:58 +01:00
- CI_JOB_NAME: dist-i686-msvc
RUST_CONFIGURE_ARGS: >
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
--build=i686-pc-windows-msvc
--target=i586-pc-windows-msvc
rust: Import LLD for linking wasm objects This commit imports the LLD project from LLVM to serve as the default linker for the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently removed along with "binaryen linker" support in rustc. Moving to LLD brings with it a number of benefits for wasm code: * LLD is itself an actual linker, so there's no need to compile all wasm code with LTO any more. As a result builds should be *much* speedier as LTO is no longer forcibly enabled for all builds of the wasm target. * LLD is quickly becoming an "official solution" for linking wasm code together. This, I believe at least, is intended to be the main supported linker for native code and wasm moving forward. Picking up support early on should help ensure that we can help LLD identify bugs and otherwise prove that it works great for all our use cases! * Improvements to the wasm toolchain are currently primarily focused around LLVM and LLD (from what I can tell at least), so it's in general much better to be on this bandwagon for bugfixes and new features. * Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which means a postprocessor is no longer needed to show off Rust's "small wasm binary size". LLD is added in a pretty standard way to rustc right now. A new rustbuild target was defined for building LLD, and this is executed when a compiler's sysroot is being assembled. LLD is compiled against the LLVM that we've got in tree, which means we're currently on the `release_60` branch, but this may get upgraded in the near future! LLD is placed into rustc's sysroot in a `bin` directory. This is similar to where `gcc.exe` can be found on Windows. This directory is automatically added to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd` linker which implements the interface that `wasm-ld`, LLD's frontend, expects. Like Emscripten the LLD target is currently only enabled for Tier 1 platforms, notably OSX/Windows/Linux, and will need to be installed manually for compiling to wasm on other platforms. LLD is by default turned off in rustbuild, and requires a `config.toml` option to be enabled to turn it on. Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD has a native option for controlling this. [gc]: https://reviews.llvm.org/D42511
2017-08-27 03:30:12 +02:00
--enable-full-tools
Enable profiler selectively on some builders
2017-06-06 19:09:33 +02:00
--enable-profiler
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
SCRIPT: python x.py dist
Add DIST_REQUIRE_ALL_TOOLS to CI scripts
2018-09-28 09:07:44 +02:00
DIST_REQUIRE_ALL_TOOLS: 1
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
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-10 00:48:58 +01:00
- CI_JOB_NAME: dist-i686-mingw
MSYS_BITS: 32
rust: Import LLD for linking wasm objects This commit imports the LLD project from LLVM to serve as the default linker for the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently removed along with "binaryen linker" support in rustc. Moving to LLD brings with it a number of benefits for wasm code: * LLD is itself an actual linker, so there's no need to compile all wasm code with LTO any more. As a result builds should be *much* speedier as LTO is no longer forcibly enabled for all builds of the wasm target. * LLD is quickly becoming an "official solution" for linking wasm code together. This, I believe at least, is intended to be the main supported linker for native code and wasm moving forward. Picking up support early on should help ensure that we can help LLD identify bugs and otherwise prove that it works great for all our use cases! * Improvements to the wasm toolchain are currently primarily focused around LLVM and LLD (from what I can tell at least), so it's in general much better to be on this bandwagon for bugfixes and new features. * Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which means a postprocessor is no longer needed to show off Rust's "small wasm binary size". LLD is added in a pretty standard way to rustc right now. A new rustbuild target was defined for building LLD, and this is executed when a compiler's sysroot is being assembled. LLD is compiled against the LLVM that we've got in tree, which means we're currently on the `release_60` branch, but this may get upgraded in the near future! LLD is placed into rustc's sysroot in a `bin` directory. This is similar to where `gcc.exe` can be found on Windows. This directory is automatically added to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd` linker which implements the interface that `wasm-ld`, LLD's frontend, expects. Like Emscripten the LLD target is currently only enabled for Tier 1 platforms, notably OSX/Windows/Linux, and will need to be installed manually for compiling to wasm on other platforms. LLD is by default turned off in rustbuild, and requires a `config.toml` option to be enabled to turn it on. Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD has a native option for controlling this. [gc]: https://reviews.llvm.org/D42511
2017-08-27 03:30:12 +02:00
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-full-tools
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
SCRIPT: python x.py dist
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-16 01:04:13 +02:00
MINGW_URL: https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror
appveyor: Upgrade to gcc for mingw 6.3.0 This commit sort of brings back #40777 by upgrading back to 6.3.0. While investigating #40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for #40184 contained in #40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes #40546
2017-04-20 17:35:03 +02:00
MINGW_ARCHIVE: i686-6.3.0-release-posix-dwarf-rt_v5-rev2.7z
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
MINGW_DIR: mingw32
Add DIST_REQUIRE_ALL_TOOLS to CI scripts
2018-09-28 09:07:44 +02:00
DIST_REQUIRE_ALL_TOOLS: 1
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
2017-01-01 02:42:40 +01:00
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-10 00:48:58 +01:00
- CI_JOB_NAME: dist-x86_64-mingw
MSYS_BITS: 64
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
SCRIPT: python x.py dist
rust: Import LLD for linking wasm objects This commit imports the LLD project from LLVM to serve as the default linker for the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently removed along with "binaryen linker" support in rustc. Moving to LLD brings with it a number of benefits for wasm code: * LLD is itself an actual linker, so there's no need to compile all wasm code with LTO any more. As a result builds should be *much* speedier as LTO is no longer forcibly enabled for all builds of the wasm target. * LLD is quickly becoming an "official solution" for linking wasm code together. This, I believe at least, is intended to be the main supported linker for native code and wasm moving forward. Picking up support early on should help ensure that we can help LLD identify bugs and otherwise prove that it works great for all our use cases! * Improvements to the wasm toolchain are currently primarily focused around LLVM and LLD (from what I can tell at least), so it's in general much better to be on this bandwagon for bugfixes and new features. * Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which means a postprocessor is no longer needed to show off Rust's "small wasm binary size". LLD is added in a pretty standard way to rustc right now. A new rustbuild target was defined for building LLD, and this is executed when a compiler's sysroot is being assembled. LLD is compiled against the LLVM that we've got in tree, which means we're currently on the `release_60` branch, but this may get upgraded in the near future! LLD is placed into rustc's sysroot in a `bin` directory. This is similar to where `gcc.exe` can be found on Windows. This directory is automatically added to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd` linker which implements the interface that `wasm-ld`, LLD's frontend, expects. Like Emscripten the LLD target is currently only enabled for Tier 1 platforms, notably OSX/Windows/Linux, and will need to be installed manually for compiling to wasm on other platforms. LLD is by default turned off in rustbuild, and requires a `config.toml` option to be enabled to turn it on. Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD has a native option for controlling this. [gc]: https://reviews.llvm.org/D42511
2017-08-27 03:30:12 +02:00
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-full-tools
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-16 01:04:13 +02:00
MINGW_URL: https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror
appveyor: Upgrade to gcc for mingw 6.3.0 This commit sort of brings back #40777 by upgrading back to 6.3.0. While investigating #40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for #40184 contained in #40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes #40546
2017-04-20 17:35:03 +02:00
MINGW_ARCHIVE: x86_64-6.3.0-release-posix-seh-rt_v5-rev2.7z
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
MINGW_DIR: mingw64
Add DIST_REQUIRE_ALL_TOOLS to CI scripts
2018-09-28 09:07:44 +02:00
DIST_REQUIRE_ALL_TOOLS: 1
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
2017-01-01 02:42:40 +01:00
DEPLOY: 1
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
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-12 02:28:29 +01:00
# "alternate" deployment, see .travis.yml for more info
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-10 00:48:58 +01:00
- CI_JOB_NAME: dist-x86_64-msvc-alt
MSYS_BITS: 64
Enable profiler on "alternate" builds This hopefully fixes #42967 and #43085.
2017-07-11 14:01:04 +02:00
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --enable-extended --enable-profiler
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-12 02:28:29 +01:00
SCRIPT: python x.py dist
DEPLOY_ALT: 1
More test fixes from rollup
2017-01-20 02:18:12 +01:00
matrix:
fast_finish: true
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 17:05:15 +01:00
clone_depth: 2
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
build: false
install:
ci: print the appveyor agent version at the start of the build
2019-03-31 23:56:09 +02:00
# Print which AppVeyor agent version we're running on.
- appveyor version
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
# If we need to download a custom MinGW, do so here and set the path
# appropriately.
#
# Note that this *also* means that we're not using what is typically
# /mingw32/bin/python2.7.exe, which is a "correct" python interpreter where
# /usr/bin/python2.7.exe is not. To ensure we use the right interpreter we
# move `C:\Python27` ahead in PATH and then also make sure the `python2.7.exe`
# file exists in there (which it doesn't by default).
travis: Make more network requests retryable This commit attempts to move more network operations to being retryable through various operations. For example git submodule updates, downloading snapshots, etc, are now all in retryable steps. Hopefully this commit can cut down on the number of network failures we've been seeing!
2017-02-25 09:00:47 +01:00
- if defined MINGW_URL appveyor-retry appveyor DownloadFile %MINGW_URL%/%MINGW_ARCHIVE%
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
- if defined MINGW_URL 7z x -y %MINGW_ARCHIVE% > nul
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
- if defined MINGW_URL set PATH=%CD%\%MINGW_DIR%\bin;C:\msys64\usr\bin;%PATH%
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
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 17:34:14 +02:00
# If we're compiling for MSVC then we, like most other distribution builders,
# switch to clang as the compiler. This'll allow us eventually to enable LTO
# amongst LLVM and rustc. Note that we only do this on MSVC as I don't think
# clang has an output mode compatible with MinGW that we need. If it does we
# should switch to clang for MinGW as well!
#
# Note that the LLVM installer is an NSIS installer
#
# Original downloaded here came from
AppVeyor: Update clang-cl from 7.0.0 to 8.0.0
2019-05-08 17:05:02 +02:00
# http://releases.llvm.org/8.0.0/LLVM-8.0.0-win64.exe
- if NOT defined MINGW_URL appveyor-retry appveyor DownloadFile https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/LLVM-8.0.0-win64.exe
- if NOT defined MINGW_URL .\LLVM-8.0.0-win64.exe /S /NCRC /D=C:\clang-rust
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 17:34:14 +02:00
- if NOT defined MINGW_URL set RUST_CONFIGURE_ARGS=%RUST_CONFIGURE_ARGS% --set llvm.clang-cl=C:\clang-rust\bin\clang-cl.exe
appveyor: Upgrade to gcc for mingw 6.3.0 This commit sort of brings back #40777 by upgrading back to 6.3.0. While investigating #40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for #40184 contained in #40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes #40546
2017-04-20 17:35:03 +02:00
# Here we do a pretty heinous thing which is to mangle the MinGW installation
# we just had above. Currently, as of this writing, we're using MinGW-w64
# builds of gcc, and that's currently at 6.3.0. We use 6.3.0 as it appears to
# be the first version which contains a fix for #40546, builds randomly
# failing during LLVM due to ar.exe/ranlib.exe failures.
#
# Unfortunately, though, 6.3.0 *also* is the first version of MinGW-w64 builds
# to contain a regression in gdb (#40184). As a result if we were to use the
# gdb provided (7.11.1) then we would fail all debuginfo tests.
#
# In order to fix spurious failures (pretty high priority) we use 6.3.0. To
# avoid disabling gdb tests we download an *old* version of gdb, specifically
# that found inside the 6.2.0 distribution. We then overwrite the 6.3.0 gdb
# with the 6.2.0 gdb to get tests passing.
#
# Note that we don't literally overwrite the gdb.exe binary because it appears
# to just use gdborig.exe, so that's the binary we deal with instead.
- if defined MINGW_URL appveyor-retry appveyor DownloadFile %MINGW_URL%/2017-04-20-%MSYS_BITS%bit-gdborig.exe
- if defined MINGW_URL mv 2017-04-20-%MSYS_BITS%bit-gdborig.exe %MINGW_DIR%\bin\gdborig.exe
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
# Otherwise pull in the MinGW installed on appveyor
- if NOT defined MINGW_URL set PATH=C:\msys64\mingw%MSYS_BITS%\bin;C:\msys64\usr\bin;%PATH%
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 18:36:52 +01:00
# Prefer the "native" Python as LLVM has trouble building with MSYS sometimes
- copy C:\Python27\python.exe C:\Python27\python2.7.exe
- set PATH=C:\Python27;%PATH%
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 20:36:52 +01:00
# Download and install sccache
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 17:34:14 +02:00
- appveyor-retry appveyor DownloadFile https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/2018-04-26-sccache-x86_64-pc-windows-msvc
- mv 2018-04-26-sccache-x86_64-pc-windows-msvc sccache.exe
Update sccache binaries on CI Currently CI builds can fail spuriously during the LLVM build (#39003). I believe this is due to sccache, and I believe that in turn was due to the fact that the sccache server used to just be a raw mio server. Historically raw mio servers are quite complicated to get right, but this is why we built Tokio! The sccache server has been migrated to Tokio which I suspect would fix any latent issues. I have no confirmation of this (never been able to reproduce the deadlock locally), but my hunch is that updating sccache to the master branch will fix the timeouts during the LLVM build. The binaries previously came from Gecko's infrastructure, but I've built new ones by hand for Win/Mac/Linux and uploaded them to our CI bucket.
2017-02-24 22:16:54 +01:00
- set PATH=%PATH%;%CD%
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 20:36:52 +01:00
appveyor: Use Ninja to build LLVM on MinGW I have a suspicion that MinGW's make is the cause of #40546 rather than anything else, but that's purely a suspicion without any facts to back it up. In any case we'll eventually be moving the MSVC build over to Ninja in order to leverage sccache regardless, so this commit simply jumpstarts that process by downloading Ninja for use by MinGW anyway. I'm not sure if this closes #40546 for real, but this is my current best shot at closing it out, so... Closes #40546
2017-03-15 15:35:35 +01:00
# Download and install ninja
#
# Note that this is originally from the github releases patch of Ninja
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-16 01:04:13 +02:00
- appveyor-retry appveyor DownloadFile https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/2017-03-15-ninja-win.zip
appveyor: Use Ninja to build LLVM on MinGW I have a suspicion that MinGW's make is the cause of #40546 rather than anything else, but that's purely a suspicion without any facts to back it up. In any case we'll eventually be moving the MSVC build over to Ninja in order to leverage sccache regardless, so this commit simply jumpstarts that process by downloading Ninja for use by MinGW anyway. I'm not sure if this closes #40546 for real, but this is my current best shot at closing it out, so... Closes #40546
2017-03-15 15:35:35 +01:00
- 7z x 2017-03-15-ninja-win.zip
appveyor: Use Ninja/sccache on MSVC Now that the final bug fixes have been merged into sccache we can start leveraging sccache on the MSVC builders on AppVeyor instead of relying on the ad-hoc caching strategy of trigger files and whatnot.
2017-02-25 18:53:46 +01:00
- set RUST_CONFIGURE_ARGS=%RUST_CONFIGURE_ARGS% --enable-ninja
appveyor: Use Ninja to build LLVM on MinGW I have a suspicion that MinGW's make is the cause of #40546 rather than anything else, but that's purely a suspicion without any facts to back it up. In any case we'll eventually be moving the MSVC build over to Ninja in order to leverage sccache regardless, so this commit simply jumpstarts that process by downloading Ninja for use by MinGW anyway. I'm not sure if this closes #40546 for real, but this is my current best shot at closing it out, so... Closes #40546
2017-03-15 15:35:35 +01:00
# - set PATH=%PATH%;%CD% -- this already happens above for sccache
rustbuild: Start building --enable-extended This commit adds a new flag to the configure script, `--enable-extended`, which is intended for specifying a desire to compile the full suite of Rust tools such as Cargo, the RLS, etc. This is also an indication that the build system should create combined installers such as the pkg/exe/msi artifacts. Currently the `--enable-extended` flag just indicates that combined installers should be built, and Cargo is itself not compiled just yet but rather only downloaded from its location. The intention here is to quickly get to feature parity with the current release process and then we can start improving it afterwards. All new files in this PR inside `src/etc/installer` are copied from the rust-packaging repository.
2017-01-21 02:03:06 +01:00
# Install InnoSetup to get `iscc` used to produce installers
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-16 01:04:13 +02:00
- appveyor-retry appveyor DownloadFile https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/2017-08-22-is.exe
appveyor: Use InnoSetup from our mirror Chocolatey has been pretty flaky, so let's not rely on it. Closes #43985
2017-08-23 04:42:28 +02:00
- 2017-08-22-is.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP-
rustbuild: Start building --enable-extended This commit adds a new flag to the configure script, `--enable-extended`, which is intended for specifying a desire to compile the full suite of Rust tools such as Cargo, the RLS, etc. This is also an indication that the build system should create combined installers such as the pkg/exe/msi artifacts. Currently the `--enable-extended` flag just indicates that combined installers should be built, and Cargo is itself not compiled just yet but rather only downloaded from its location. The intention here is to quickly get to feature parity with the current release process and then we can start improving it afterwards. All new files in this PR inside `src/etc/installer` are copied from the rust-packaging repository.
2017-01-21 02:03:06 +01:00
- set PATH="C:\Program Files (x86)\Inno Setup 5";%PATH%
appveyor: Attempt to debug flaky test runs This commit is an attempt to debug #38620 since we're unable to reproduce it locally. It follows the [advice] of those with AppVeyor to use the `handle.exe` tool to try to debug what processes have a handle to the file open. This won't be guaranteed to actually help us, but hopefully it'll diagnose something at some point? [advice]: http://help.appveyor.com/discussions/questions/2898
2016-12-30 00:58:57 +01:00
# Help debug some handle issues on AppVeyor
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-16 01:04:13 +02:00
- appveyor-retry appveyor DownloadFile https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/2017-05-15-Handle.zip
appveyor: Attempt to debug flaky test runs This commit is an attempt to debug #38620 since we're unable to reproduce it locally. It follows the [advice] of those with AppVeyor to use the `handle.exe` tool to try to debug what processes have a handle to the file open. This won't be guaranteed to actually help us, but hopefully it'll diagnose something at some point? [advice]: http://help.appveyor.com/discussions/questions/2898
2016-12-30 00:58:57 +01:00
- mkdir handle
appveyor: Wrap handle.exe download in a retry Should help deal with spurious download failures.
2017-05-14 21:41:42 +02:00
- 7z x -ohandle 2017-05-15-Handle.zip
appveyor: Attempt to debug flaky test runs This commit is an attempt to debug #38620 since we're unable to reproduce it locally. It follows the [advice] of those with AppVeyor to use the `handle.exe` tool to try to debug what processes have a handle to the file open. This won't be guaranteed to actually help us, but hopefully it'll diagnose something at some point? [advice]: http://help.appveyor.com/discussions/questions/2898
2016-12-30 00:58:57 +01:00
- set PATH=%PATH%;%CD%\handle
- handle.exe -accepteula -help
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
test_script:
Enable appveyor cache, add more paranoia
2017-04-04 23:51:16 +02:00
- if not exist C:\cache\rustsrc\NUL mkdir C:\cache\rustsrc
- sh src/ci/init_repo.sh . /c/cache/rustsrc
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 21:31:19 +01:00
- set SRC=.
- set NO_CCACHE=1
Revert "Rollup merge of #58162 - pietroalbini:track-259, r=alexcrichton" This reverts commit 4c243e2c3d8f02cdcd22fe68acf6a0b3edca2078, reversing changes made to 64f0032a3739b18ae45387744340d9c7ce48b145.
2019-02-06 15:16:50 +01:00
- sh src/ci/run.sh
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
AppVeyor: Dump crash log on failure.
2018-05-11 06:30:50 +02:00
on_failure:
# Dump crash log
- set PATH=%PATH%;"C:\Program Files (x86)\Windows Kits\10\Debuggers\X64"
- if exist %LOCALAPPDATA%\CrashDumps for %%f in (%LOCALAPPDATA%\CrashDumps\*) do cdb -c "k;q" -G -z "%%f"
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
branches:
only:
- auto
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
2017-01-01 02:42:40 +01:00
before_deploy:
- ps: |
New-Item -Path deploy -ItemType directory
travis: Tweak artifact uploads * Don't upload `*.wixpdb` files by accident * Don't upload `doc` dir by accident * Fix level of indirection on Travis
2017-01-28 19:24:42 +01:00
Remove-Item -Recurse -Force build\dist\doc
travis: Upload all artifacts in build/dist Previously we only uploaded tarballs, but this modifies Travis/AppVeyor to upload everything. We shouldn't have anything else in there to worry about and otherwise we need to be sure to pick up pkg/msi/exe installers.
2017-01-25 20:55:30 +01:00
Get-ChildItem -Path build\dist | Move-Item -Destination deploy
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
2017-01-01 02:42:40 +01:00
Get-ChildItem -Path deploy | Foreach-Object {
Push-AppveyorArtifact $_.FullName -FileName ${env:APPVEYOR_REPO_COMMIT}/$_
}
deploy:
- provider: S3
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 11:29:53 +02:00
access_key_id: $(AWS_ACCESS_KEY_ID)
secret_access_key: $(AWS_SECRET_ACCESS_KEY)
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-16 01:04:13 +02:00
bucket: rust-lang-ci2
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
2017-01-01 02:42:40 +01:00
set_public: true
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-16 01:04:13 +02:00
region: us-west-1
travis: Upload all artifacts in build/dist Previously we only uploaded tarballs, but this modifies Travis/AppVeyor to upload everything. We shouldn't have anything else in there to worry about and otherwise we need to be sure to pick up pkg/msi/exe installers.
2017-01-25 20:55:30 +01:00
artifact: /.*/
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
2017-01-01 02:42:40 +01:00
folder: rustc-builds
on:
branch: auto
DEPLOY: 1
appveyor: Leverage auto-retry to upload to S3 This was recently implemented (appveyor/ci#1387) in response to one of our feature requests, so let's take advantage of it! I'm going to optimistically say... Closes #39074
2017-03-23 15:07:02 +01:00
max_error_retry: 5
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
2017-01-01 02:42:40 +01:00
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-12 02:28:29 +01:00
# This provider is the same as the one above except that it has a slightly
# different upload directory and a slightly different trigger
- provider: S3
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 11:29:53 +02:00
access_key_id: $(AWS_ACCESS_KEY_ID)
secret_access_key: $(AWS_SECRET_ACCESS_KEY)
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-16 01:04:13 +02:00
bucket: rust-lang-ci2
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-12 02:28:29 +01:00
set_public: true
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-16 01:04:13 +02:00
region: us-west-1
travis: Add builders without assertions This commit adds three new builders, one OSX, one Linux, and one MSVC, which will produce "nightlies" with LLVM assertions disabled. Currently all nightly releases have LLVM assertions enabled to catch bugs before they reach the beta/stable channels. The beta/stable channels, however, do not have LLVM assertions enabled. Unfortunately though projects like Servo are stuck on nightlies for the near future at least and are also suffering very long compile times. The purpose of this commit is to provide artifacts to these projects which are not distributed through normal channels (e.g. rustup) but are provided for developers to use locally if need be. Logistically these builds will all be uploaded to `rustc-builds-alt` instead of the `rustc-builds` folder of the `rust-lang-ci` bucket. These builds will stay there forever (until cleaned out if necessary) and there are no plans to integrate this with rustup and/or the official release process.
2017-02-12 02:28:29 +01:00
artifact: /.*/
folder: rustc-builds-alt
on:
branch: auto
DEPLOY_ALT: 1
appveyor: Leverage auto-retry to upload to S3 This was recently implemented (appveyor/ci#1387) in response to one of our feature requests, so let's take advantage of it! I'm going to optimistically say... Closes #39074
2017-03-23 15:07:02 +01:00
max_error_retry: 5
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-12 02:28:29 +01:00
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 18:43:26 +02:00
# init:
# - ps: iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))
# on_finish:
# - ps: $blockRdp = $true; iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))
Reference in New Issue Copy Permalink