| Age | Commit message (Collapse) | Author | Lines |
|
We need to add runners designed for an aarch64 host system, and it'd be
nice to return an error message if someone tries to run an image
designed for an host architecture in another one.
To start the work on this, this commit moves all the existing builders
in the host-x86_64 directory, and changes the run.sh script to look up
the image in the correct directory based on the host architecture.
|
|
|
|
|
|
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.
|
|
Ensure that they're all forwards-compatible with AWS updates happening
next year by ensuring the bucket name shows up in the domain name.
Closes #61168
|
|
|
|
These arguments are passed to the relevant x.py invocation in all cases
anyway. As such, there is no need to separately configure them. x.py
will ignore the configuration when they are passed on the command line
anyway.
|
|
Newer versions of Docker have a `--init` argument which spawns an init process
in the container, which we should be able to use everywhere now.
|
|
This commit adds a disabled builder which will run all tests for the standard
library for aarch64 in a QEMU instance. Once we get enough capacity to run this
on Travis this can be used to boost our platform coverage of AArch64
|
|
|
|
|
|
This commit updates the sccache binaries to fix a cache load failure seen
on #41926, fixed by mozilla/sccache#119
|
|
Pulls in mozilla/sccache@ef0d77543 to fix #40240 again after the builds included
in #41447 forgot to include the mio fixed included in #41076.
Closes #40240
|
|
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.
|
|
This build is no longer a forked version with temporary bugfixes, everything
should be upstreamed!
|
|
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.
|
|
Looks like the last version was built with mio 0.6.5 which now has known bugs
against it. This build includes mio 0.6.6
|
|
|
|
I've built a local copy with mozilla/sccache#79 and mozilla/sccache#78. Let's
see if that helps #40240!
|
|
Now that mozilla/sccache#43 is fixed the caching works for MinGW on Windows. We
still can't use it for MSVC just yet, but I'll try to revive that branch at some
point.
|
|
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.
|
|
This commit adds support to the build system to execute test suites that cannot
run natively but can instead run inside of a QEMU emulator. A proof-of-concept
builder was added for the `arm-unknown-linux-gnueabihf` target to show off how
this might work.
In general the architecture is to have a server running inside of the emulator
which a local client connects to. The protocol between the server/client
supports compiling tests on the host and running them on the target inside the
emulator.
Closes #33114
|