Pull Request, Auto, and Try Builds in Rust CI

kinds of builds (sets of jobs). 1. PR builds 2. Auto builds 3. Try builds ### Pull Request builds After each push to a pull request, a set of `pr` jobs are executed. Currently, these execute the `x86_64-gnu-llvm-X`, `x86_64-gnu-tools`, `mingw-check-1`, `mingw-check-2` and `mingw-check-tidy` jobs, all running on Linux. These execute a relatively short (~40 minutes) and lightweight test suite that should catch common issues. More specifically, they run a set of lints, they try to perform a cross-compile check build to Windows mingw (without producing any artifacts) and they test the compiler using a *system* version of LLVM. Unfortunately, it would take too many resources to run the full test suite for each commit on every PR. > **Note on doc comments** > > Note that PR CI as of Oct 2024  by default does not try to > run `./x doc xxx`. This means that if you have any broken intradoc links that > would lead to `./x doc xxx` failing, it will happen very late into the full > merge queue CI pipeline. > > Thus, it is a good idea to run `./x doc xxx` locally for any doc comment > changes to help catch these early. PR jobs are defined in the `pr` section of [`jobs.yml`]. They run under the `rust-lang/rust` repository, and their results can be observed directly on the PR, in the "CI checks" section at the bottom of the PR page. ### Auto builds Before a commit can be merged into the `master` branch, it needs to pass our complete test suite. We call this an `auto` build. This build runs tens of CI jobs that exercise various tests across operating systems and targets. The full test suite is quite slow; it can take two hours or more until all the `auto` CI jobs finish. 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]). Auto jobs are defined in the `auto` section of [`jobs.yml`]. They are executed on the `auto` branch under the `rust-lang/rust` repository and their results can be seen [here](https://github.com/rust-lang/rust/actions), although usually you will be notified of the result by a comment made by bors on the corresponding PR. At any given time, at most a single `auto` build is being executed. Find out more [here](#merging-prs-serially-with-bors). ### Try builds Sometimes we want to run a subset of the test suite on CI for a given PR, or build a set of compiler artifacts from that PR, without attempting to merge it. We call this a "try build". A try build is started after a user with the proper permissions posts a PR comment with the `@bors try` command. There are several use-cases for try builds: - Run a set of performance benchmarks using our [rustc-perf] benchmark suite. For this, a working compiler build is needed, which can be generated with a try build that runs the [dist-x86_64-linux] CI job, which builds an optimized version of the compiler on Linux (this job is currently executed by default when you start a try build). To create a try build and schedule it for a performance benchmark, you can use the `@bors try @rust-timer queue` command combination. - Check the impact of the PR across the Rust ecosystem, using a [crater] run. Again, a working compiler build is needed for this, which can be produced by the [dist-x86_64-linux] CI job. - Run a specific CI job (e.g. Windows tests) on a PR, to quickly test if it passes the test suite executed by that job. By default, if you send a comment with `@bors try`, the jobs defined in the `try` section of [`jobs.yml`] will be executed. We call this mode a "fast try build". Such a try build will not execute any tests, and it will allow compilation warnings. It is useful when you want to get an optimized toolchain as fast as possible, for a crater run or performance benchmarks, even if it might not be working fully correctly. If you want to run a custom CI job in a try build and make sure that it passes all tests and does not produce any compilation warnings, you can select CI jobs to be executed by adding lines

This section details the three types of builds in the Rust CI system: Pull Request (PR) builds, Auto builds, and Try builds. PR builds execute a lightweight test suite on each PR push to catch common issues. Auto builds run the complete test suite before merging into the `master` branch, ensuring comprehensive testing across various platforms. Try builds allow running a subset of the test suite or building compiler artifacts on demand, often used for performance benchmarks, crater runs, or testing specific CI jobs. Try builds are initiated with the `@bors try` command.