Skip to content

Adjust mentions about CI to GitHub Actions #816

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 2, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
2 changes: 1 addition & 1 deletion src/notification-groups/llvm.md
Original file line number Diff line number Diff line change
Expand Up @@ -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).
Expand Down
24 changes: 13 additions & 11 deletions src/tests/intro.md
Original file line number Diff line number Diff line change
Expand Up @@ -116,27 +116,29 @@ 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.
Comment on lines +127 to +128
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to the limit on the number of parallel jobs

Is this correct? @Mark-Simulacrum

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

## 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
Expand Down Expand Up @@ -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
Expand Down
6 changes: 3 additions & 3 deletions src/tests/running.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
4 changes: 2 additions & 2 deletions src/walkthrough.md
Original file line number Diff line number Diff line change
Expand Up @@ -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!

Expand Down