@@ -184,9 +184,9 @@ copy such constructs when working on a new test plan from scratch
184
184
185
185
When a job is both included and excluded, exclusion always takes priority.
186
186
187
- .. _Test Plan category-overrides field :
187
+ .. _Test Plan category_overrides field :
188
188
189
- ``category-overrides ``:
189
+ ``category_overrides ``:
190
190
A multi-line list of category override statements.
191
191
192
192
This optional field can be used to alter the natural job definition
@@ -218,7 +218,7 @@ copy such constructs when working on a new test plan from scratch
218
218
219
219
apply CATEGORY-IDENTIFIER to JOB-DEFINITION-PATTERN
220
220
221
- Both ' apply' and 'to' are literal strings. CATEGORY-IDENTIFIER is
221
+ Both `` apply `` and `` to `` are literal strings. CATEGORY-IDENTIFIER is
222
222
the identifier of a category unit. The JOB-DEFINITION-PATTERN has the
223
223
same syntax as the ``include `` field does. That is, it can be either
224
224
a simple string or a regular expression that is being compared to
@@ -236,6 +236,45 @@ copy such constructs when working on a new test plan from scratch
236
236
The job definition with the partial identifier ``foo `` will be associated
237
237
with the ``cat-2 `` category.
238
238
239
+ .. _Test Plan certification_status_overrides field :
240
+
241
+ ``certification_status_overrides ``:
242
+ A multi-line list of certification status override statements.
243
+
244
+ Similar to the :ref: `category_overrides<Test Plan category_overrides field> `
245
+ field, this field can be used to modify the certification status of the
246
+ jobs matching the given regular expression.
247
+
248
+ The possible values are the same as for the
249
+ :ref: `certification-status<Job certification-status field> ` job field.
250
+
251
+ For instance, the following will force every wireless job to become a
252
+ certification blocker::
253
+
254
+ apply blocker to .*wireless.*
255
+
256
+ .. note ::
257
+
258
+ This override mechanism “bubbles up”, meaning if it is used in a
259
+ :ref: `nested part<nested-test-plan> `, all the jobs selected as part of
260
+ the whole test plan will be impacted, not only the jobs in that
261
+ specific nested part.
262
+
263
+ .. warning ::
264
+
265
+ If no namespace is provided, Checkbox will add the namespace of the
266
+ current provider to the regular expression that is provided. This can
267
+ be a problem if the override has to work across different providers
268
+ with different namespaces. In that case, instead of using::
269
+
270
+ apply blocker to .*
271
+
272
+ the following should be used::
273
+
274
+ apply blocker to .*::.*
275
+
276
+ to apply the override to every job of every namespaces.
277
+
239
278
.. _Test Plan estimated_duration field :
240
279
241
280
``estimated_duration ``:
0 commit comments