You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/tests/ci.md
+23-23Lines changed: 23 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -84,16 +84,15 @@ resources to run the full test suite for each commit on every PR.
84
84
> Thus, it is a good idea to run `./x doc xxx` locally for any doc comment
85
85
> changes to help catch these early.
86
86
87
-
PR jobs are defined in the `pr` section of [`jobs.yml`]. They run under the
88
-
`rust-lang/rust` repository, and their results can be observed directly on the
89
-
PR, in the "CI checks" section at the bottom of the PR page.
87
+
PR jobs are defined in the `pr` section of [`jobs.yml`]. Their results can be observed
88
+
directly on the PR, in the "CI checks" section at the bottom of the PR page.
90
89
91
90
### Auto builds
92
91
93
92
Before a commit can be merged into the `master` branch, it needs to pass our
94
93
complete test suite. We call this an `auto` build. This build runs tens of CI
95
94
jobs that exercise various tests across operating systems and targets. The full
96
-
test suite is quite slow; it can take two hours or more until all the `auto` CI
95
+
test suite is quite slow; it can take several hours until all the `auto` CI
97
96
jobs finish.
98
97
99
98
Most platforms only run the build steps, some run a restricted set of tests,
@@ -136,13 +135,21 @@ By default, if you send a comment with `@bors try`, the jobs defined in the `try
136
135
[`jobs.yml`] will be executed. We call this mode a "fast try build". Such a try build
137
136
will not execute any tests, and it will allow compilation warnings. It is useful when you want to
138
137
get an optimized toolchain as fast as possible, for a crater run or performance benchmarks,
139
-
even if it might not be working fully correctly.
140
-
141
-
If you want to run a custom CI job in a try build and make sure that it passes all tests and does
142
-
not produce any compilation warnings, you can select CI jobs to be executed by providing them in
143
-
the bors command like so: `@bors try jobs=<job pattern>`.
144
-
145
-
Each pattern can either be an exact name of a job or a glob pattern that matches multiple jobs,
138
+
even if it might not be working fully correctly. If you want to do a full build for the default try job,
139
+
specify its job name in a job pattern (explained below).
140
+
141
+
If you want to run custom CI job(s) in a try build and make sure that they pass all tests and do
142
+
not produce any compilation warnings, you can select CI jobs to be executed by specifying a *job pattern*,
143
+
which can be used in one of two ways:
144
+
- You can add a set of `try-job: <job pattern>` directives to the PR description (described below) and then
145
+
simply run `@bors try`. CI will read these directives and run the jobs that you have specified. This is
146
+
useful if you want to rerun the same set of try jobs multiple times, after incrementally modifying a PR.
147
+
- You can specify the job pattern using the `jobs` parameter of the try command: `@bors try jobs=<job pattern>`.
148
+
This is useful for one-off try builds with specific jobs. Note that the `jobs` parameter has a higher priority
149
+
than the PR description directives.
150
+
- There can also be multiple patterns specified, e.g. `@bors try jobs=job1,job2,job3`.
151
+
152
+
Each job pattern can either be an exact name of a job or a glob pattern that matches multiple jobs,
146
153
for example `*msvc*` or `*-alt`. You can start at most 20 jobs in a single try build. When using
147
154
glob patterns, you might want to wrap them in backticks (`` ` ``) to avoid GitHub rendering
148
155
the pattern as Markdown.
@@ -181,26 +188,19 @@ of [`jobs.yml`]:
181
188
> However, it can be less flexible because you cannot adjust the set of tests
182
189
> that are exercised this way.
183
190
184
-
Try jobs are defined in the `try` section of [`jobs.yml`]. They are executed on
185
-
the `try` branch under the `rust-lang/rust` repository and
191
+
Try builds are executed on the `try` branch under the `rust-lang/rust` repository and
186
192
their results can be seen [here](https://github.com/rust-lang/rust/actions),
187
193
although usually you will be notified of the result by a comment made by bors on
188
194
the corresponding PR.
189
195
190
-
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`).
196
+
Multiple try builds can execute concurrently across different PRs, but there can be at most
197
+
a single try build running on a single PR at any given time.
191
198
192
-
Multiple try builds can execute concurrently across different PRs.
193
-
194
-
<div class="warning">
195
-
196
-
Bors identifies try jobs by commit hash. This means that if you have two PRs
197
-
containing the same (latest) commits, running `@bors try` will result in the
198
-
*same* try job and it really confuses `bors`. Please refrain from doing so.
199
-
200
-
</div>
199
+
Note that try builds are handled using the new [bors][new-bors] implementation.
0 commit comments