| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
This reverts commit 1dfb6b162be402d8ca37e8aad4f58898b44e3a15, reversing
changes made to bcb5798dd890a691644af9d371f3bd7fcc465584.
That commit broke generating nightly rustc docs. Revert it until we can figure out how to have both, cranelift and docs.
|
|
|
|
|
|
|
|
|
|
When docker-podman compat was set up in a way that causes "docker"
to be the argv[0] of podman, the previous detection did not work.
This was for example the case in the compat package from nixpkgs.
This checks the output and should work everywhere.
|
|
summary
|
|
|
|
|
|
Currently, having a dirty `obj/` directory is sufficient to abort CI
tests. This results in errors like the following:
```
...
== end clock drift check ==
sccache: Starting the server...
configure: error: Existing 'config.toml' detected.
== clock drift check ==
...
```
This is subtle and doesn't give a good idea as to what causes the issue.
With this patch, the error becomes more prominent and a resolution is
suggested:
```
== end clock drift check ==
sccache: Starting the server...
configure: ERROR: Existing 'config.toml' detected. Exiting
Is objdir '/home/tmgross/projects/rust/obj' clean?
== clock drift check ==
```
|
|
This also adds a dynamic check that we don't emit nested groups, since GHA currently doesn't support them.
|
|
CI: merge x86_64-gnu-llvm-14 and x86_64-gnu-llvm-14-stage1 CI jobs
Another attempt to shorten CI job times. Suggested by `@the8472` [here](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/CI.20usage/near/367172221).
|
|
|
|
|
|
|
|
|
|
Rootless podman creates a separate user namespace, where an inner
`LOCAL_USER_ID` will map to a different subuid range on the host.
The "keep-id" mode maps the current UID directly into the container.
This makes `src/ci/docker/run.sh` work better for testing container
images on systems running podman, where "docker" is just a shim.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
not emitted
|
|
During the 1.52 release process we had to deal with some commits that
passed the test suite on the nightly branch but failed on the beta or
stable branch. In that case it was due to some UI tests including the
channel name in the output, but other changes might also be dependent on
the channel.
This commit adds a new CI job that runs the Linux x86_64 test suite with
the stable branch, ensuring nightly changes also work as stable.
|
|
When the dockerfiles were moved into the host-x86_64 directory, paths
for COPY commands were updated with the new host-x86_64/ prefix. This
suggested that the intended context was src/ci/docker. However, the context
for disabled docker images was src/ci/docker/host-x86_64. This broke the new
paths and prevented src/ci/docker/scripts from being included in the
context at all.
This commit corrects this context allowing docker to find the files it
needs for COPY commands.
|
|
We're starting to include native aarch64 machines in our CI, but before
this commit the architecture wasn't included in the cache key for our
Docker images. This means there could be conflicts between images
produced on different architectures, hurting our CI times.
This commit fixes the problem by including the output of `uname -m` in
the cache key.
|
|
|
|
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.
|
|
|
|
This will reduce costs, as well as lays the groundwork for developers to be able
to locally pull the published docker images without needing AWS credentials.
|
|
|
|
Before this commit toolstates.json was stored in /tmp and it wasn't
mounted outside the build container. That caused uploading the file in
the upload-artifacts task to fail, as the file was missing on the host.
Mounting /tmp/toolstates.json alone is not the best approach: if the
file is missing when the container is started the Docker engine will
create a *directory* named /tmp/toolstates.json.
The Docker issue could be solved by pre-creating an empty file named
/tmp/toolstates.json, but doing that could cause problems if bootstrap
fails to generate the file and the toolstate scripts receive an empty
JSON.
The approach I took in this commit is to instead mount a /tmp/toolstate
directory inside Docker, and create the toolstates.json file in it. That
also required a small bootstrap change to ensure the directory is
created if it's missing.
|
|
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.
|
|
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!
|
|
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!
|
|
Currently just run it through its paces but don't actually push to
official locations. Instead let's just push to a separate fork (mine) as
well as open issues in a separate fork (mine). Make sure that people
aren't pinged for these issues as well!
This should hopefully ensure that everything is working on Azure and
give us a chance to work through any issues that come up.
|
|
|
|
|
|
|
|
This writes an extra `dist/image-$image.txt` which contains the S3 URL
of the cached image and the `sha256` digest of the docker entry point.
This will be uploaded with the rest of the deployed artifacts in the
Travis `after_success` script.
|
|
`src/ci/docker`, so that when files under `dist-x86_64-linux` is changed,
its dependent image `dist-i686-linux` will also be rebuilt.
However, this ultraconservative solution caused the `dist-i686-linux` to
be rebuilt every time an irrelevant Dockerfile (e.g. the PowerPC ones) is
changed, which increases the building time beyond 3 hours and forcing
a spurious but expected failure.
This commit instead parses the Dockerfile itself and look for the actual
dependencies. The scripts needs to be copied into the Docker image, which
must be done with the COPY command, so we just need to find all lines with
a COPY command and add the source file into the hash calculator.
Note: this script only handles single-lined COPY command in the form
`COPY src1 src2 src3 dst`, since these are the only variant used inside
this repository.
|
|
|
|
Before this commit the hash used to cache docker images was calculated
from the image's files and the files in the scripts/ directory. This
worked fine when all the files used by an image were in those
directories, but some images pull files from other images, causing hash
collisions in some cases.
This commit changes the hash to include the files of all the docker
images, causing a rebuild of all the images when a single one changes.
That's a bit heavy-handed, but we have no way to track which files an
image pulls in and hash collisions are really painful to deal with.
|
|
In theory we shouldn't require trusty so long as docker continues to
work!
|
|
|
|
This reverts commit 32e8bda4e35ada92beab7236d62520e6c6df8596.
|
