mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-26 19:55:39 +00:00
4d387f2490
The task description now includes * flexible specification of index routes (this will get simpler once buildbot and gecko.v1 routes are removed) * "run-on-projects", indicating the projects on which this task should run * "{level}" is allowed in workerTypes * For the docker-worker/docker-engine worker implementations, "docker-image" can have the form {in-tree: in-tree-name} to use an in-tree image. This was previously implemented in the test transforms, but it is useful for other tasks too! * Optimizations, currently limited to "only-if-files-changed", can be specified for each task. * TreeHerder groupSymbol is optional * expires-after and and deadline-after have default values (with the former differing for try and non-try) * coalesce-name triggers creation of both a coalesce route and a superseder URL MozReview-Commit-ID: 70vtYs5lz5P --HG-- extra : rebase_source : 9c557d68239f42466d9724d48ed5bf77648f9aa0
139 lines
4.2 KiB
ReStructuredText
139 lines
4.2 KiB
ReStructuredText
===============
|
|
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.
|
|
|
|
kind
|
|
====
|
|
|
|
A task's ``kind`` attribute gives the name of the kind that generated it, e.g.,
|
|
``build`` or ``legacy``.
|
|
|
|
|
|
run_on_projects
|
|
===============
|
|
|
|
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 specified explicitly in try syntax.
|
|
|
|
task_duplicates
|
|
===============
|
|
|
|
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.
|
|
|
|
build_platform
|
|
==============
|
|
|
|
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
|
|
``test_platform``.
|
|
|
|
build_type
|
|
==========
|
|
|
|
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``
|
|
|
|
test_platform
|
|
=============
|
|
|
|
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``.
|
|
|
|
unittest_suite
|
|
==============
|
|
|
|
This is the unit test suite being run in a unit test task. For example,
|
|
``mochitest`` or ``cppunittest``.
|
|
|
|
unittest_flavor
|
|
===============
|
|
|
|
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``.
|
|
|
|
unittest_try_name
|
|
=================
|
|
|
|
(deprecated) 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``.
|
|
|
|
talos_try_name
|
|
==============
|
|
|
|
(deprecated) This is the name used to refer to a talos job via try syntax.
|
|
|
|
test_chunk
|
|
==========
|
|
|
|
This is the chunk number of a chunked test suite (talos or unittest). Note
|
|
that this is a string!
|
|
|
|
e10s
|
|
====
|
|
|
|
For test suites which distinguish whether they run with or without e10s, this
|
|
boolean value identifies this particular run.
|
|
|
|
legacy_kind
|
|
===========
|
|
|
|
(deprecated) The kind of task as created by the legacy kind. This is valid
|
|
only for the ``legacy`` kind. One of ``build``, ``unittest,``, ``talos``,
|
|
``post_build``, or ``job``.
|
|
|
|
job
|
|
===
|
|
|
|
(deprecated) The name of the job (corresponding to a ``-j`` option or the name
|
|
of a post-build job). This is valid only for the ``legacy`` kind.
|
|
|
|
post_build
|
|
==========
|
|
|
|
(deprecated) The name of the post-build activity. This is valid only for the
|
|
``legacy`` kind.
|
|
|
|
image_name
|
|
==========
|
|
|
|
For the ``docker_image`` kind, this attribute contains the docker image name.
|