Adjust mentions about CI to GitHub Actions

README.md

@@ -103,13 +103,16 @@ 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 toolstate due to the spurious failure,
+but we leave this 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.
 

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).

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]).
+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]).
 
-[Azure Pipelines]: https://dev.azure.com/rust-lang/rust/
+[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
@@ -262,7 +264,7 @@ 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
 `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

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

src/walkthrough.md

@@ -192,7 +192,7 @@ 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
 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!