ci: move linkcheck from mingw-2 to mingw-1
Running UI tests now takes a huge amount of time on mingw builders
(between 40 and 50 minutes), with mingw-1 builders taking even an hour
less to finish than mingw-2. This PR moves linkcheck from mingw-2 to
mingw-1, removing between 10 and 20 minutes of runtime on the -2
builders.
r? @alexcrichton
Running UI tests now takes a huge amount of time on mingw builders
(between 40 and 50 minutes), with mingw-1 builders taking even an hour
less to finish than mingw-2. This PR moves linkcheck from mingw-2 to
mingw-1, removing between 10 and 20 minutes of runtime on the -2
builders.
ci: add a check for clock drift
Recently we encountered multiple spurious failures where the crates.io
certificate was reported as expired, even though it's currently due to
expire in a few months. This adds some code to our CI to check for clock
drifts, to possibly find the cause or rule out a bad VM clock.
cc https://github.com/rust-lang/rust/issues/63510
r? @Mark-Simulacrum
Recently we encountered multiple spurious failures where the crates.io
certificate was reported as expired, even though it's currently due to
expire in a few months. This adds some code to our CI to check for clock
drifts, to possibly find the cause or rule out a bad VM clock.
Currently mirrors are stored in the rust-lang-ci2 S3 bucket along with
CI toolchains. This is problematic for multiple reasons:
- CI IAM credentials are allowed to both edit and delete those files.
A malicious user gaining access to those credentials would be able to
change our mirrored dependencies, possibly backdooring the compiler.
- Contents of the rust-lang-ci2 bucket are disposable except for the
mirrors' content. When we implement backups for S3 buckets we'd have
to replicate just that part of the bucket, complicating the backup
logic and increasing the chance of mistakes. A standalone bucket will
be way easier to backup.
This commit switches our CI to use the new rust-lang-ci-mirrors bucket.
Added support for armv7-unknown-linux-gnueabi/musleabi
Fixes#63101
Some things that are not done and I hope someone can help me with:
* During the ci build of `armv7-unknown-linux-gnueabi` `openssl` must be built (to build cargo) but `openssl` does not yet support this target. This feels slightly like a chicken-and-egg problem, any feedback is welcome.
* Should I add any tests for any of these targets?
ci: fix toolstate not pushing data for Linux
A recent commit modified toolstate to only push updated data when the `TOOLSTATE_PUBLISH` environment variable is present. This worked fine on Windows but failed on Linux, since Linux jobs run inside Docker containers and the variable wasn't forwarded inside it.
This changes the Docker startup code to set the `TOOLSTATE_PUBLISH` enviornment variable inside the container if it's present outside.
r? @alexcrichton
fixes https://github.com/rust-lang/rust/issues/63190
A recent commit modified toolstate to only push updated data when the
TOOLSTATE_PUBLISH environment variable is present. This worked fine on
Windows but failed on Linux, since Linux jobs run inside Docker
containers and the variable wasn't forwarded inside it.
This changes the Docker startup code to set the TOOLSTATE_PUBLISH
enviornment variable inside the container if it's present outside.
ci: download awscli from our mirror
This fixes multiple network issues we had when downloading awscli from PyPI on Azure Pipelines by vendoring awscli itself and its dependencies in our S3 bucket. Instructions on how to update the cache are present at the top of `src/ci/install-awscli.sh`.
r? @alexcrichton or @Mark-Simulacrum
fixes#62967
This fixes multiple network issues we had when downloading awscli from
PyPI on Azure Pipelines by vendoring awscli itself and its dependencies
in our S3 bucket. Instructions on how to update the cache are present at
the top of src/ci/install-awscli.sh
ci: gate toolstate repo pushes on the TOOLSTATE_PUBLISH envvar
This PR fixes toolstate failing to push on the LinuxTools PR builder by gating the pushes on the new `TOOLSTATE_PUBLISH` environment variable, which is set on prod credentials but not on the PR ones. The old code checked whether the access token was set, but that doesn't work due to an Azure quirk.
For a bit of background, secret environment variables are not available by default, but each step needs to explicitly declare which secret vars to load:
```yaml
- bash: echo foo
env:
SECRET_VAR: $(SECRET_VAR)
```
This works fine when the variable is present but when it's missing, instead of setting `SECRET_VAR` to an empty string or just not setting it at all, Azure Pipelines puts the literal `$(SECRET_VAR)` as the content, which completly breaks the old check we had. I tried almost every thing to make this work in a sensible way, and the only conclusion I reached is to set the variable at the top level with the runtime expression evaluation syntax, which sets the variable to an empty string if missing:
```yaml
# At the top:
variables:
- name: MAYBE_SECRET_VAR
value: $[ variables.MAYBE_SECRET_VAR ]
# In the step:
- bash: echo foo
env:
SECRET_VAR: $(MAYBE_SECRET_VAR)
```
While that *could've worked* it was ugly and messy, so I just opted to add yet another non-secret variable.
r? @alexcrichton
fixes#62811
Unfortunately due to an Azure quirk the TOOLSTATE_REPO_ACCESS_TOKEN is
not suitable to gate whether to push new commits to the repo, as if it's
not defined on the Azure side it will actually be set to the literal
`$(TOOLSTATE_REPO_ACCESS_TOKEN)`, which screws everything up.
This instead adds another, non-secret environment variable to gate
publishing: TOOLSTATE_PUBLISH. As non-secret environment variables
behave correctly this fixes the issue.
Require a value for configure --debuginfo-level
In `configure.py`, using the `o` function creates an enable/disable
boolean setting, and writes `true` or `false` in `config.toml`. However,
rustbuild is expecting to parse a `u32` debuginfo level. We can change
to the `v` function to have the options require a value.
In `configure.py`, using the `o` function creates an enable/disable
boolean setting, and writes `true` or `false` in `config.toml`. However,
rustbuild is expecting to parse a `u32` debuginfo level. We can change
to the `v` function to have the options require a value.
docutils 0.15, a dependency of awscli, broke our CI since it's not
compatible with Python 2 due to a bug. This pins all the dependencies of
awscli with docutils 0.14, to make sure this kind of regressions doesn't
happen again.
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!
Update to LLVM 9 trunk
Following the preparatory changes in #62474, this updates the LLVM submodule to https://github.com/rust-lang/llvm-project/tree/rustc/9.0-2019-07-12 and:
* Changes the LLVM Rust bindings to account for the new SubtargetSubTypeKV.
* Adjusts a codegen test for the new form of the byval attribute that takes a type.
* Makes a PGO codegen test more liberal with regard to order and linkage.
* Builds InstrProfilingPlatformWindows.c as part of libprofiler_builtins.
* Moves registration of additional passes (in particular sanitizers) to the end of the module pass manager.
* Disables LLDB on builders.
r? @alexcrichton
Now that we've fully moved to Azure Pipelines and bors has been updated
to only gate on Azure this commit removes the remaining Travis/AppVeyor
support contained in this repository. Most of the deletions here are
related to producing better output on Travis by folding certain
sections. This isn't supported by Azure so there's no need to keep it
around, and if Azure ever adds support we can always add it back!
