author Greg Mierzwinski <gmierz2@outlook.com>
Sat, 24 Sep 2016 14:31:25 -0400
changeset 425012 4125e49eaee483b08624f3f341f0b9904807b446
parent 415630 33d031e3454e1bdd1bb94ada0b918c48d7935067
child 430304 9eadaf5e0c05cd7adf39e2598c390ce64d3e9567
permissions -rw-r--r--
Bug 1305242 - Disable linux64-jsdcov and linux64-ccov from running on try with '-u all'. r?dustin This patch prevents tests which have the 'run_on_projects' attribute assigned to an empty set from running when the try message contains '-p all' and '-u all' together. It also makes the 'match_test' function a little more readable and updates the 'attributes.rst' document to reflect the changes that were made. MozReview-Commit-ID: IMk0cmSza8U

Task Attributes

Tasks can be filtered, for example to support "try" pushes which only perform a
subset of the task graph or to link dependent tasks.  This filtering is the
difference between a full task graph and a target task graph.

Filtering takes place on the basis of attributes.  Each task has a dictionary
of attributes and filters over those attributes can be expressed in Python.  A
task may not have a value for every attribute.

The attributes, and acceptable values, are defined here.  In general, attribute
names and values are the short, lower-case form, with underscores.


A task's ``kind`` attribute gives the name of the kind that generated it, e.g.,
``build`` or ``spidermonkey``.


The projects where this task should be in the target task set.  This is how
requirements like "only run this on inbound" get implemented.  These are
either project names or the aliases

 * `integration` -- integration branches
 * `release` -- release branches including mozilla-central
 * `all` -- everywhere (the default)

For try, this attribute applies only if ``-p all`` is specified.  All jobs can
be specified by name regardless of ``run_on_projects``.

If ``run_on_projects`` is set to an empty list, then the task will not run
anywhere, unless its build platform is specified explicitly in try syntax.


This is used to indicate that we want multiple copies of the task created.
This feature is used to track down intermittent job failures.

If this value is set to N, the task-creation machinery will create a total of N
copies of the task.  Only the first copy will be included in the taskgraph
output artifacts, although all tasks will be contained in the same taskGroup.

While most attributes are considered read-only, target task methods may alter
this attribute of tasks they include in the target set.


The build platform defines the platform for which the binary was built.  It is
set for both build and test jobs, although test jobs may have a different


The type of build being performed.  This is a subdivision of ``build_platform``,
used for different kinds of builds that target the same platform.  Values are

 * ``debug``
 * ``opt``


The test platform defines the platform on which tests are run.  It is only
defined for test jobs and may differ from ``build_platform`` when the same binary
is tested on several platforms (for example, on several versions of Windows).
This applies for both talos and unit tests.

Unlike build_platform, the test platform is represented in a slash-separated
format, e.g., ``linux64/opt``.


This is the unit test suite being run in a unit test task.  For example,
``mochitest`` or ``cppunittest``.


If a unittest suite has subdivisions, those are represented as flavors.  Not
all suites have flavors, in which case this attribute should be set to match
the suite.  Examples: ``mochitest-devtools-chrome-chunked`` or ``a11y``.


This is the name used to refer to a unit test via try syntax.  It
may not match either of ``unittest_suite`` or ``unittest_flavor``.


This is the name used to refer to a talos job via try syntax.


This is the chunk number of a chunked test suite (talos or unittest).  Note
that this is a string!


For test suites which distinguish whether they run with or without e10s, this
boolean value identifies this particular run.


For the ``docker_image`` kind, this attribute contains the docker image name.


Signals whether the task is part of a nightly graph. Useful when filtering
out nightly tasks from full task set at target stage.