gecko-dev/taskcluster/docs/attributes.rst
Dustin J. Mitchell ffca84ff7d Bug 1281004: Specify test tasks more flexibly; r=gps; r=gbrown
This introduces a completely new way of specifying test task in-tree,
completely replacing the old spider-web of YAML files.

The high-level view is this:

 - some configuration files are used to determine which test suites to run
   for each test platform, and against which build platforms

 - each test suite is then represented by a dictionary, and modified by a
   sequence of transforms, duplicating as necessary (e.g., chunks), until
   it becomes a task definition

The transforms allow sufficient generality to support just about any desired
configuration, with the advantage that common configurations are "easy" while
unusual configurations are supported but notable for their oddness (they
require a custom transform).

As of this commit, this system produces the same set of test graphs as the
existing YAML, modulo:

  - extra.treeherder.groupName -- this was not consistent in the YAML
  - extra.treeherder.build -- this is ignored by taskcluster-treeherder anyway
  - mozharness command argument order
  - boolean True values for environment variables are now the string "true"
  - metadata -- this is now much more consistent, with task name being the label

Testing of this commit demonstrates that it produces the same set of test tasks for
the following projects (those which had special cases defined in the YAML):

  - autoland
  - ash (*)
  - willow
  - mozilla-inbound
  - mozilla-central
  - try:
    -b do -p all -t all -u all
    -b d -p linux64,linux64-asan -u reftest -t none
    -b d -p linux64,linux64-asan -u reftest[x64] -t none[x64]

(*) this patch omits the linux64/debug tc-M-e10s(dt) test, which is enabled on
ash; ash will require a small changeset to re-enable this test.

IGNORE BAD COMMIT MESSAGES (because the hook flags try syntax!)

MozReview-Commit-ID: G34dg9f17Hq

--HG--
rename : taskcluster/taskgraph/kind/base.py => taskcluster/taskgraph/task/base.py
rename : taskcluster/taskgraph/kind/docker_image.py => taskcluster/taskgraph/task/docker_image.py
rename : taskcluster/taskgraph/kind/legacy.py => taskcluster/taskgraph/task/legacy.py
extra : rebase_source : 03e70902c2d3a297eb9e3ce852f8737c2550d5a6
extra : histedit_source : d4d9f4b192605af21f41d83495fc3c923759c3cb
2016-07-11 23:27:14 +00:00

108 lines
3.0 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``.
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.