Details on Try Builds and Modifying CI Jobs

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 containing `try-job: <job pattern>` to the PR description. All such specified jobs will be executed in the try build once the `@bors try` command is used on the PR. Each pattern can either be an exact name of a job or a glob pattern that matches multiple jobs, for example `*msvc*` or `*-alt`. You can start at most 20 jobs in a single try build. When using glob patterns, you might want to wrap them in backticks (`` ` ``) to avoid GitHub rendering the pattern as Markdown. > **Using `try-job` PR description directives** > > 1. Identify which set of try-jobs you would like to exercise. You can > find the name of the CI jobs in [`jobs.yml`]. > > 2. Amend PR description to include a set of patterns (usually at the end > of the PR description), for example: > > ```text > This PR fixes #123456. > > try-job: x86_64-msvc > try-job: test-various > try-job: `*-alt` > ``` > > Each `try-job` pattern must be on its own line. > > 3. Run the prescribed try jobs with `@bors try`. As aforementioned, this > requires the user to either (1) have `try` permissions or (2) be delegated > with `try` permissions by `@bors delegate` by someone who has `try` > permissions. > > Note that this is usually easier to do than manually edit [`jobs.yml`]. > However, it can be less flexible because you cannot adjust the set of tests > that are exercised this way. Try jobs are defined in the `try` section of [`jobs.yml`]. They are executed on the `try` 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. Note that if you start the default try job using `@bors try`, it will skip building several `dist` components and running post-optimization tests, to make the build duration shorter. If you want to execute the full build as it would happen before a merge, add an explicit `try-job` pattern with the name of the default try job (currently `dist-x86_64-linux`). Multiple try builds can execute concurrently across different PRs. <div class="warning"> Bors identifies try jobs by commit hash. This means that if you have two PRs containing the same (latest) commits, running `@bors try` will result in the *same* try job and it really confuses `bors`. Please refrain from doing so. </div> [rustc-perf]: https://github.com/rust-lang/rustc-perf [crater]: https://github.com/rust-lang/crater ### Modifying CI jobs If you want to modify what gets executed on our CI, you can simply modify the `pr`, `auto` or `try` sections of the [`jobs.yml`] file. You can also modify what gets executed temporarily, for example to test a particular platform or configuration that is challenging to test locally (for example, if a Windows build fails, but you don't have access to a Windows machine). Don't hesitate to use CI resources in such situations to try out a fix! You can perform an arbitrary CI job in two ways:

This section provides detailed information on try builds, including their use cases for performance benchmarks, crater runs, and testing specific CI jobs. It explains how to initiate a 'fast try build' with `@bors try` and how to specify custom CI jobs by adding `try-job: <job pattern>` lines to the PR description. The section also covers how to modify CI jobs by editing the `jobs.yml` file and mentions that multiple try builds can run concurrently. Additionally, it provides a warning against running `@bors try` on two PRs containing the same commits.