mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
ca2dce9b48
rust/appveyor.yml

211 lines
8.0 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 11:43:26 -05: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 13:36:52 -06: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 11:43:26 -05: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 11:36:52 -06: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 11:43:26 -05: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 11:36:52 -06:00
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc
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 11:43:26 -05: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 11:36:52 -06: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 11:43:26 -05: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 11:36:52 -06: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 11:43:26 -05: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 11:55:16 -06: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 14:31:19 -06: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 11:43:26 -05:00
# 32/64-bit MinGW builds.
#
# The MinGW builds unfortunately have to both download a custom toolchain and
# avoid the one installed by AppVeyor by default. Interestingly, though, for
# different reasons!
#
# For 32-bit the installed gcc toolchain on AppVeyor uses the pthread
# threading model. This is unfortunately not what we want, and if we compile
# with it then there's lots of link errors in the standard library (undefined
# references to pthread symbols).
#
# For 64-bit the installed gcc toolchain is currently 5.3.0 which
# unfortunately segfaults on Windows with --enable-llvm-assertions (segfaults
# in LLVM). See rust-lang/rust#28445 for more information, but to work around
# this we go back in time to 4.9.2 specifically.
#
# 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.
#
# And as a final point of note, the 32-bit MinGW build using the makefiles do
# *not* use debug assertions and llvm assertions. This is because they take
# too long on appveyor and this is tested by rustbuild below.
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 11:36:52 -06:00
- MSYS_BITS: 32
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 09:35:35 -05:00
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja
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 11:36:52 -06: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 17:46:40 -05:00
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
appveyor: Downgrade MinGW to 6.2.0 It looks like the 6.3.0 MinGW comes with a gdb which has issues (#40184) that an attempted workaround (#40777) does not actually fix (#40835). The original motivation for upgradin MinGW was to fix build flakiness (#40546) due to newer builds not exhibiting the same bug, so let's hope that 6.2.0 isn't too far back in time and still contains the fix we need. Closes #40835
2017-03-27 15:06:56 -05:00
MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.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 11:36:52 -06:00
MINGW_DIR: mingw32
- MSYS_BITS: 64
SCRIPT: python x.py test
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 09:35:35 -05:00
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja
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 17:46:40 -05:00
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
appveyor: Downgrade MinGW to 6.2.0 It looks like the 6.3.0 MinGW comes with a gdb which has issues (#40184) that an attempted workaround (#40777) does not actually fix (#40835). The original motivation for upgradin MinGW was to fix build flakiness (#40546) due to newer builds not exhibiting the same bug, so let's hope that 6.2.0 isn't too far back in time and still contains the fix we need. Closes #40835
2017-03-27 15:06:56 -05:00
MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.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 11:36:52 -06:00
MINGW_DIR: mingw64
# 32/64 bit MSVC and GNU deployment
- RUST_CONFIGURE_ARGS: >
--build=x86_64-pc-windows-msvc
--enable-extended
SCRIPT: python x.py dist
DEPLOY: 1
- RUST_CONFIGURE_ARGS: >
--build=i686-pc-windows-msvc
--target=i586-pc-windows-msvc
--enable-extended
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 11:43:26 -05:00
- MSYS_BITS: 32
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 09:35:35 -05:00
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja
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 11:36:52 -06: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 17:46:40 -05:00
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
appveyor: Downgrade MinGW to 6.2.0 It looks like the 6.3.0 MinGW comes with a gdb which has issues (#40184) that an attempted workaround (#40777) does not actually fix (#40835). The original motivation for upgradin MinGW was to fix build flakiness (#40546) due to newer builds not exhibiting the same bug, so let's hope that 6.2.0 isn't too far back in time and still contains the fix we need. Closes #40835
2017-03-27 15:06:56 -05:00
MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.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 11:43:26 -05: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
2016-12-31 19:42:40 -06: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 11:43:26 -05: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 11:36:52 -06:00
SCRIPT: python x.py dist
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 09:35:35 -05:00
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja
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 17:46:40 -05:00
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
appveyor: Downgrade MinGW to 6.2.0 It looks like the 6.3.0 MinGW comes with a gdb which has issues (#40184) that an attempted workaround (#40777) does not actually fix (#40835). The original motivation for upgradin MinGW was to fix build flakiness (#40546) due to newer builds not exhibiting the same bug, so let's hope that 6.2.0 isn't too far back in time and still contains the fix we need. Closes #40835
2017-03-27 15:06:56 -05:00
MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.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 11:43:26 -05: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
2016-12-31 19:42:40 -06: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 11:43:26 -05: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-11 19:28:29 -06: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-19 19:18:12 -06: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 11:43:26 -05: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 02:00:47 -06: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 11:43:26 -05: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 11:36:52 -06: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 11:43:26 -05: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 11:36:52 -06: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 13:36:52 -06:00
# Download and install sccache
travis: Update sccache binaries I've tracked down what I believe is the last spurious sccache failure on #40240 to behavior in mio (carllerche/mio#583), and this commit updates the binaries to a version which has that fix incorporated.
2017-04-04 17:55:23 -05:00
- appveyor-retry appveyor DownloadFile https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-04-04-sccache-x86_64-pc-windows-msvc
- mv 2017-04-04-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 15:16:54 -06: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 13:36:52 -06: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 09:35:35 -05: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
# - 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-20 19:03:06 -06: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 02:00:47 -06: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-20 19:03:06 -06: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-29 17:58:57 -06:00
# Help debug some handle issues on AppVeyor
- ps: Invoke-WebRequest -Uri https://download.sysinternals.com/files/Handle.zip -OutFile handle.zip
- mkdir handle
- ps: Expand-Archive handle.zip -dest handle
- 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 11:06:44 -06: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 11:43:26 -05:00
test_script:
Enable appveyor cache, add more paranoia
2017-04-04 16:51:16 -05: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 14:31:19 -06: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 11:43:26 -05: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 11:06:44 -06:00
on_failure:
Enable appveyor cache, add more paranoia
2017-04-04 16:51:16 -05:00
- cat %CD%\sccache.log
- cat C:\Users\appveyor\AppData\Local\Temp\1\build-cache-logs\*.log
Attempt to debug sccache in more locations This should hopefully add support for debugging OSX and Windows presumed sccache failures instead of just the Linux ones.
2017-03-11 11:06:44 -06:00
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 11:43:26 -05:00
cache:
Enable appveyor cache, add more paranoia
2017-04-04 16:51:16 -05:00
- C:\cache\rustsrc
rustbuild: Add option for enabling partial LLVM rebuilds
2017-03-07 14:20:39 -06:00
- "build/i686-pc-windows-msvc/llvm -> src/rustllvm/llvm-rebuild-trigger"
- "build/x86_64-pc-windows-msvc/llvm -> src/rustllvm/llvm-rebuild-trigger"
- "i686-pc-windows-msvc/llvm -> src/rustllvm/llvm-rebuild-trigger"
- "x86_64-pc-windows-msvc/llvm -> src/rustllvm/llvm-rebuild-trigger"
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 11:43:26 -05: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
2016-12-31 19:42:40 -06: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 12:24:42 -06: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 13:55:30 -06: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
2016-12-31 19:42:40 -06: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 13:55:30 -06: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
2016-12-31 19:42:40 -06: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 09:07:02 -05: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
2016-12-31 19:42:40 -06: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-11 19:28:29 -06: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 09:07:02 -05: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-11 19:28:29 -06: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 11:43:26 -05: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