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

215 lines
8.3 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:
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
SCCACHE_BUCKET: rust-lang-ci-sccache
AWS_ACCESS_KEY_ID: AKIAIMX7VLAS3PZAVLUQ
AWS_SECRET_ACCESS_KEY:
secure: 1UkmbiDd15tWtYbMm5O2Uqm0b0Ur8v1MoSlydxl4ojcroPeerRMlUges0l57py8c
SCCACHE_DIGEST: f808afabb4a4eb1d7112bcb3fa6be03b61e93412890c88e177c667eb37f46353d7ec294e559b16f9f4b5e894f2185fe7670a0df15fd064889ecbd80f0c34166c
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
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
- 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
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
- MSYS_BITS: 32
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
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-msvc --target=i586-pc-windows-msvc
SCRIPT: python x.py test --host i686-pc-windows-msvc --target i686-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
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
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
- MSYS_BITS: 64
rustbuild: Don't run pretty tests by default This commit relegates all pretty tests to not get run by default and rather get run as part of an "aux" test suite. This "aux" suite is renamed from the old "cargotest" suite to just collect tests that don't need to run everywhere but should at least pass on Unix/Windows.
2016-12-29 18:55:16 +01:00
RUST_CHECK_TARGET: check-aux
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
# 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.
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
- 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
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: Upgrade MinGW toolchains we use In debugging #40546 I was able to reproduce locally finally using the literal toolchain that the bots were using. I reproduced the error maybe 4 in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which has yet to have a failed build. When attempting to reproduce the bug with the toolchain that this commit switches to I was unable to reproduce anything after a few builds. I have no idea what the original problem was, but I'm hoping that it was just some random bug fixed somewhere along the way. I don't currently know of a technical reason to stick to the 4.9.2 toolchains we were previously using. Historcal 5.3.* toolchains would cause llvm to segfault (maybe a miscompile?) but this seems to have been fixed recently. To me if it passes CI then I think we're good. Closes #40546
2017-03-23 23:46:40 +01:00
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/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
- MSYS_BITS: 64
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
appveyor: Upgrade MinGW toolchains we use In debugging #40546 I was able to reproduce locally finally using the literal toolchain that the bots were using. I reproduced the error maybe 4 in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which has yet to have a failed build. When attempting to reproduce the bug with the toolchain that this commit switches to I was unable to reproduce anything after a few builds. I have no idea what the original problem was, but I'm hoping that it was just some random bug fixed somewhere along the way. I don't currently know of a technical reason to stick to the 4.9.2 toolchains we were previously using. Historcal 5.3.* toolchains would cause llvm to segfault (maybe a miscompile?) but this seems to have been fixed recently. To me if it passes CI then I think we're good. Closes #40546
2017-03-23 23:46:40 +01:00
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/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
# 32/64 bit MSVC and GNU deployment
- RUST_CONFIGURE_ARGS: >
--build=x86_64-pc-windows-msvc
--enable-extended
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
DEPLOY: 1
- RUST_CONFIGURE_ARGS: >
--build=i686-pc-windows-msvc
--target=i586-pc-windows-msvc
--enable-extended
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
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
- MSYS_BITS: 32
Don't enable profiler on MinGW targets, as compiler-rt can't currently be compiled with MinGW
2017-06-07 13:50:50 +02:00
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended
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
appveyor: Upgrade MinGW toolchains we use In debugging #40546 I was able to reproduce locally finally using the literal toolchain that the bots were using. I reproduced the error maybe 4 in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which has yet to have a failed build. When attempting to reproduce the bug with the toolchain that this commit switches to I was unable to reproduce anything after a few builds. I have no idea what the original problem was, but I'm hoping that it was just some random bug fixed somewhere along the way. I don't currently know of a technical reason to stick to the 4.9.2 toolchains we were previously using. Historcal 5.3.* toolchains would cause llvm to segfault (maybe a miscompile?) but this seems to have been fixed recently. To me if it passes CI then I think we're good. Closes #40546
2017-03-23 23:46:40 +01:00
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/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
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
- 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
Don't enable profiler on MinGW targets, as compiler-rt can't currently be compiled with MinGW
2017-06-07 13:50:50 +02:00
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended
appveyor: Upgrade MinGW toolchains we use In debugging #40546 I was able to reproduce locally finally using the literal toolchain that the bots were using. I reproduced the error maybe 4 in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which has yet to have a failed build. When attempting to reproduce the bug with the toolchain that this commit switches to I was unable to reproduce anything after a few builds. I have no idea what the original problem was, but I'm hoping that it was just some random bug fixed somewhere along the way. I don't currently know of a technical reason to stick to the 4.9.2 toolchains we were previously using. Historcal 5.3.* toolchains would cause llvm to segfault (maybe a miscompile?) but this seems to have been fixed recently. To me if it passes CI then I think we're good. Closes #40546
2017-03-23 23:46:40 +01:00
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/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
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
- MSYS_BITS: 64
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --enable-extended
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
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
clone_depth: 1
build: false
install:
# 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
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
Update sccache binaries to mozilla/sccache@d3627d766 This commit updates the sccache binaries to fix a cache load failure seen on #41926, fixed by mozilla/sccache#119
2017-05-12 18:07:10 +02:00
- appveyor-retry appveyor DownloadFile https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-05-12-sccache-x86_64-pc-windows-msvc
- mv 2017-05-12-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
- appveyor-retry appveyor DownloadFile https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-03-15-ninja-win.zip
- 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
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
- appveyor-retry choco install -y InnoSetup
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
appveyor: Wrap handle.exe download in a retry Should help deal with spurious download failures.
2017-05-14 21:41:42 +02:00
- appveyor-retry appveyor DownloadFile https://s3.amazonaws.com/rust-lang-ci/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
Attempt to debug sccache in more locations This should hopefully add support for debugging OSX and Windows presumed sccache failures instead of just the Linux ones.
2017-03-11 18:06:44 +01:00
# Attempt to debug sccache failures
- set SCCACHE_ERROR_LOG=%CD%/sccache.log
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
- 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
Attempt to debug sccache in more locations This should hopefully add support for debugging OSX and Windows presumed sccache failures instead of just the Linux ones.
2017-03-11 18:06:44 +01:00
on_failure:
Add a comment for disabling errexit
2017-04-08 09:39:31 +02:00
- cat %CD%\sccache.log || exit 0
Attempt to debug sccache in more locations This should hopefully add support for debugging OSX and Windows presumed sccache failures instead of just the Linux ones.
2017-03-11 18:06:44 +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
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
skip_cleanup: true
access_key_id: AKIAIPQVNYF2T3DTYIWQ
secret_access_key:
secure: +11jsUNFTQ9dq5Ad1i2+PeUJaXluFJ0zIJAXESE1dFT3Kdjku4/eDdgyjgsB6GnV
bucket: rust-lang-ci
set_public: true
region: us-east-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
skip_cleanup: true
access_key_id: AKIAIPQVNYF2T3DTYIWQ
secret_access_key:
secure: +11jsUNFTQ9dq5Ad1i2+PeUJaXluFJ0zIJAXESE1dFT3Kdjku4/eDdgyjgsB6GnV
bucket: rust-lang-ci
set_public: true
region: us-east-1
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