9b4f6de7a4
This commit updates some of our assorted Azure/CI configuration to prepare for some 4-core machines coming online. We're still in the process of performance testing them to get final numbers, but some changes are worth landing ahead of this. The updates here are: * Use `C:/` instead of `D:/` for submodule checkout since it should have plenty of space and the 4-core machines won't have `D:/` * Update `lzma-sys` to 0.1.14 which has support for VS2019, where 0.1.10 doesn't. * Update `src/ci/docker/run.sh` to work when it itself is running inside of a docker container (see the comment in the file for more info) * Print step timings on the `try` branch in addition to the `auto` branch in. The logs there should be seen by similarly many humans (not many) and can be useful for performance analysis after a `try` build runs. * Install the WIX and InnoSetup tools manually on Windows instead of relying on pre-installed copies on the VM. This gives us more control over what's being used on the Azure cloud right now (we control the version) and in the 4-core machines these won't be pre-installed. Note that on AppVeyor we actually already were installing InnoSetup, we just didn't carry that over on Azure!
120 lines
6.1 KiB
YAML
120 lines
6.1 KiB
YAML
steps:
|
|
# We use the WIX toolset to create combined installers for Windows, and these
|
|
# binaries are downloaded from
|
|
# https://github.com/wixtoolset/wix3 originally
|
|
- bash: |
|
|
set -e
|
|
curl -O https://rust-lang-ci2.s3-us-west-1.amazonaws.com/rust-ci-mirror/wix311-binaries.zip
|
|
echo "##vso[task.setvariable variable=WIX]`pwd`/wix"
|
|
mkdir -p wix/bin
|
|
cd wix/bin
|
|
7z x ../../wix311-binaries.zip
|
|
displayName: Install wix
|
|
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))
|
|
|
|
# We use InnoSetup and its `iscc` program to also create combined installers.
|
|
# Honestly at this point WIX above and `iscc` are just holdovers from
|
|
# oh-so-long-ago and are required for creating installers on Windows. I think
|
|
# one is MSI installers and one is EXE, but they're not used so frequently at
|
|
# this point anyway so perhaps it's a wash!
|
|
- script: |
|
|
powershell -Command "$ProgressPreference = 'SilentlyContinue'; iwr -outf is-install.exe https://rust-lang-ci2.s3.amazonaws.com/rust-ci-mirror/2017-08-22-is.exe"
|
|
is-install.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP-
|
|
echo ##vso[task.prependpath]C:\Program Files (x86)\Inno Setup 5
|
|
displayName: Install InnoSetup
|
|
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))
|
|
|
|
# We've had issues with the default drive in use running out of space during a
|
|
# build, and it looks like the `C:` drive has more space than the default `D:`
|
|
# drive. We should probably confirm this with the azure pipelines team at some
|
|
# point, but this seems to fix our "disk space full" problems.
|
|
- script: |
|
|
mkdir c:\MORE_SPACE
|
|
mklink /J build c:\MORE_SPACE
|
|
displayName: "Ensure build happens on C:/ instead of D:/"
|
|
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))
|
|
|
|
- bash: git config --replace-all --global core.autocrlf false
|
|
displayName: "Disable git automatic line ending conversion (on C:/)"
|
|
|
|
# Download and install MSYS2, needed primarily for the test suite (run-make) but
|
|
# also used by the MinGW toolchain for assembling things.
|
|
#
|
|
# FIXME: we should probe the default azure image and see if we can use the MSYS2
|
|
# toolchain there. (if there's even one there). For now though this gets the job
|
|
# done.
|
|
- script: |
|
|
set MSYS_PATH=%CD%\citools\msys64
|
|
choco install msys2 --params="/InstallDir:%MSYS_PATH% /NoPath" -y
|
|
set PATH=%MSYS_PATH%\usr\bin;%PATH%
|
|
pacman -S --noconfirm --needed base-devel ca-certificates make diffutils tar
|
|
IF "%MINGW_URL%"=="" (
|
|
IF "%MSYS_BITS%"=="32" pacman -S --noconfirm --needed mingw-w64-i686-toolchain mingw-w64-i686-cmake mingw-w64-i686-gcc mingw-w64-i686-python2
|
|
IF "%MSYS_BITS%"=="64" pacman -S --noconfirm --needed mingw-w64-x86_64-toolchain mingw-w64-x86_64-cmake mingw-w64-x86_64-gcc mingw-w64-x86_64-python2
|
|
)
|
|
where rev
|
|
rev --help
|
|
where make
|
|
|
|
echo ##vso[task.setvariable variable=MSYS_PATH]%MSYS_PATH%
|
|
echo ##vso[task.prependpath]%MSYS_PATH%\usr\bin
|
|
displayName: Install msys2
|
|
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))
|
|
|
|
# If we need to download a custom MinGW, do so here and set the path
|
|
# appropriately.
|
|
#
|
|
# Here we also do a pretty heinous thing which is to mangle the MinGW
|
|
# installation we just downloaded. 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.
|
|
- script: |
|
|
powershell -Command "$ProgressPreference = 'SilentlyContinue'; iwr -outf %MINGW_ARCHIVE% %MINGW_URL%/%MINGW_ARCHIVE%"
|
|
7z x -y %MINGW_ARCHIVE% > nul
|
|
powershell -Command "$ProgressPreference = 'SilentlyContinue'; iwr -outf 2017-04-20-%MSYS_BITS%bit-gdborig.exe %MINGW_URL%/2017-04-20-%MSYS_BITS%bit-gdborig.exe"
|
|
mv 2017-04-20-%MSYS_BITS%bit-gdborig.exe %MINGW_DIR%\bin\gdborig.exe
|
|
echo ##vso[task.prependpath]%CD%\%MINGW_DIR%\bin
|
|
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'), ne(variables['MINGW_URL'],''))
|
|
displayName: Download custom MinGW
|
|
|
|
# Otherwise pull in the MinGW installed on appveyor
|
|
- script: |
|
|
echo ##vso[task.prependpath]%MSYS_PATH%\mingw%MSYS_BITS%\bin
|
|
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'), eq(variables['MINGW_URL'],''))
|
|
displayName: Add MinGW to path
|
|
|
|
# Make sure we use the native python interpreter instead of some msys equivalent
|
|
# one way or another. The msys interpreters seem to have weird path conversions
|
|
# baked in which break LLVM's build system one way or another, so let's use the
|
|
# native version which keeps everything as native as possible.
|
|
- script: |
|
|
copy C:\Python27amd64\python.exe C:\Python27amd64\python2.7.exe
|
|
echo ##vso[task.prependpath]C:\Python27amd64
|
|
displayName: Prefer the "native" Python as LLVM has trouble building with MSYS sometimes
|
|
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))
|
|
|
|
# Note that this is originally from the github releases patch of Ninja
|
|
- script: |
|
|
md ninja
|
|
powershell -Command "$ProgressPreference = 'SilentlyContinue'; iwr -outf 2017-03-15-ninja-win.zip https://rust-lang-ci2.s3.amazonaws.com/rust-ci-mirror/2017-03-15-ninja-win.zip"
|
|
7z x -oninja 2017-03-15-ninja-win.zip
|
|
del 2017-03-15-ninja-win.zip
|
|
set RUST_CONFIGURE_ARGS=%RUST_CONFIGURE_ARGS% --enable-ninja
|
|
echo ##vso[task.setvariable variable=RUST_CONFIGURE_ARGS]%RUST_CONFIGURE_ARGS%
|
|
echo ##vso[task.prependpath]%CD%\ninja
|
|
displayName: Download and install ninja
|
|
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))
|