diff --git a/README.md b/README.md index 345b38589..5dbd5d27f 100644 --- a/README.md +++ b/README.md @@ -103,13 +103,17 @@ There is not a workaround for this error at the moment. Comment out the `[outpu ## How to fix toolstate failures +> **NOTE**: Currently, we do not track the rustc-dev-guide toolstate due to +[the spurious failure](https://github.com/rust-lang/rust/pull/71731), +but we leave this instructions for when we do it again in the future. + 1. You will get a ping from the toolstate commit. e.g. https://github.com/rust-lang-nursery/rust-toolstate/commit/8ffa0e4c30ac9ba8546b7046e5c4ccc2b96ebdd4 2. The commit contains a link to the PR that caused the breakage. e.g. https://github.com/rust-lang/rust/pull/64321 3. If you go to that PR's thread, there is a post from bors with a link to the CI status: https://github.com/rust-lang/rust/pull/64321#issuecomment-529763807 -4. Follow the check-azure link to get to the Azure website for that build: https://dev.azure.com/rust-lang/e71b0ddf-dd27-435a-873c-e30f86eea377/_build/results?buildId=7780 +4. Follow the check-actions link to get to the Actions page for that build 5. There will be approximately 1 billion different jobs for the build. They are for different configurations and platforms. The rustc-dev-guide build only runs on the Linux x86_64-gnu-tools job. So click on that job in the list, which is about 60% down in the list. diff --git a/src/notification-groups/llvm.md b/src/notification-groups/llvm.md index d657231f2..f1f2097e5 100644 --- a/src/notification-groups/llvm.md +++ b/src/notification-groups/llvm.md @@ -21,7 +21,7 @@ questions. The ["Debugging LLVM"][d] section of the rustc-dev-guide gives a step-by-step process for how to help debug bugs caused by LLVM. In particular, it discusses how to emit LLVM IR, run -the LLVM IR optimization pipeliness, and so forth. You may also find +the LLVM IR optimization pipelines, and so forth. You may also find it useful to look at the various codegen options listed under `-Chelp` and the internal options under `-Zhelp` -- there are a number that pertain to LLVM (just search for LLVM). diff --git a/src/tests/intro.md b/src/tests/intro.md index 125e2c931..3503e7ad1 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -116,19 +116,21 @@ including: ## Testing infrastructure -When a Pull Request is opened on Github, [Azure Pipelines] will automatically +When a Pull Request is opened on Github, [GitHub Actions] will automatically launch a build that will run all tests on some configurations -(x86_64-gnu-llvm-6.0 linux. x86_64-gnu-tools linux, mingw-check linux). In +(x86_64-gnu-llvm-8 linux. x86_64-gnu-tools linux, mingw-check linux). In essence, it runs `./x.py test` after building for each of them. The integration bot [bors] is used for coordinating merges to the master branch. When a PR is approved, it goes into a [queue] where merges are tested -one at a time on a wide set of platforms using Azure Pipelines (currently over -50 different configurations). Most platforms only run the build steps, some run -a restricted set of tests, only a subset run the full suite of tests (see -Rust's [platform tiers]). - -[Azure Pipelines]: https://dev.azure.com/rust-lang/rust/ +one at a time on a wide set of platforms using GitHub Actions (currently over +50 different configurations). Due to the limit on the number of parallel jobs, +we run CI under the [rust-lang-ci] organization except for PRs. +Most platforms only run the build steps, some run a restricted set of tests, +only a subset run the full suite of tests (see Rust's [platform tiers]). + +[GitHub Actions]: https://github.com/rust-lang/rust/actions +[rust-lang-ci]: https://github.com/rust-lang-ci/rust/actions [bors]: https://github.com/servo/homu [queue]: https://buildbot2.rust-lang.org/homu/queue/rust [platform tiers]: https://forge.rust-lang.org/release/platform-support.html#rust-platform-support @@ -136,7 +138,7 @@ Rust's [platform tiers]). ## Testing with Docker images The Rust tree includes [Docker] image definitions for the platforms used on -Azure Pipelines in [`src/ci/docker`]. The script [`src/ci/docker/run.sh`] is used to build +GitHub Actions in [`src/ci/docker`]. The script [`src/ci/docker/run.sh`] is used to build the Docker image, run it, build Rust within the image, and run the tests. You can run these images on your local development machine. This can be @@ -260,9 +262,9 @@ above instructions for testing on a remote machine (in this case the remote machine is emulated). There is also a set of tools for orchestrating running the -tests within the emulator. Platforms such as `arm-android` and +tests within the emulator. Platforms such as `arm-android` and `arm-unknown-linux-gnueabihf` are set up to automatically run the tests under -emulation on Travis. The following will take a look at how a target's tests +emulation on GitHub Actions. The following will take a look at how a target's tests are run under emulation. The Docker image for [armhf-gnu] includes [QEMU] to emulate the ARM CPU diff --git a/src/tests/running.md b/src/tests/running.md index 1a6805132..1043f87a1 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -9,9 +9,9 @@ you will almost never want to use! – is as follows: This will build the stage 1 compiler and then run the whole test suite. You probably don't want to do this very often, because it takes -a very long time, and anyway bors / travis will do it for you. (Often, -I will run this command in the background after opening a PR that I -think is done, but rarely otherwise. -nmatsakis) +a very long time, and anyway bors / GitHub Actions will do it for you. +(Often, I will run this command in the background after opening a PR that +I think is done, but rarely otherwise. -nmatsakis) The test results are cached and previously successful tests are `ignored` during testing. The stdout/stderr contents as well as a diff --git a/src/walkthrough.md b/src/walkthrough.md index 9963692c7..8a41b3dd8 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -190,9 +190,9 @@ recognize that the PR won't be merged unless someone on the rust team approves it. When your reviewer approves the PR, it will go into a queue for yet another bot -called `@bors`. `@bors` manages the CI build/merge queue. When your PR reaches +called `@bors`. `@bors` manages the CI build/merge queue. When your PR reaches the head of the `@bors` queue, `@bors` will test out the merge by running all -tests against your PR on Travis CI. This takes a lot of time to +tests against your PR on GitHub Actions. This takes a lot of time to finish. If all tests pass, the PR is merged and becomes part of the next nightly compiler!