author CuriousLearner <sanyam.khurana01@gmail.com>
Thu, 20 Oct 2016 18:25:34 +0530
changeset 326973 f374e4333d3a17f72d89063670115d71a9643a5f
parent 326444 9d0c5328c89782f32bb458487278944bf219a417
child 327265 f427b837088a13502f60a2c77faf76387b0b03d0
permissions -rw-r--r--
Bug 1302763 - Move docker images out of testing/docker into taskcluster/docker; r=dustin r=CuriousLearner MozReview-Commit-ID: 7v1uCDB5qoN

Task Kinds

This section lists and documents the available task kinds.


Builds are tasks that produce an installer or other output that can be run by
users or automated tests.  This is more restrictive than most definitions of
"build" in a Mozilla context: it does not include tasks that run build-like
actions for static analysis or to produce instrumented artifacts.



This kind performs an artifact build: one based on precompiled binaries
discovered via the TaskCluster index.  This task verifies that such builds
continue to work correctly.


Hazard builds are similar to "regular' builds, but use a compiler extension to
extract a bunch of data from the build and then analyze that data looking for
hazardous behaviors.


TBD (Callek)


Source-checks are tasks that look at the Gecko source directly to check
correctness.  This can include linting, Python unit tests, source-code
analysis, or measurement work -- basically anything that does not require a


Upload-symbols tasks run after builds and upload the symbols files generated by
build tasks to Socorro for later use in crash analysis.


Valgrind tasks produce builds instrumented by valgrind.


Static analysis builds use the compiler to perform some detailed analysis of
the source code while building.  The useful output from these tasks are their
build logs, and while they produce a binary, they do not upload it as an


Toolchain builds create the compiler toolchains used to build Firefox.  These
will eventually be dependencies of the builds themselves, but for the moment
are run manually via try pushes and the results uploaded to tooltool.


Spidermonkey tasks check out the full gecko source tree, then compile only the
spidermonkey portion.  Each task runs specific tests after the build.


TBD (Maja)


Test tasks for Gecko products are divided into several kinds, but share a
common implementation.  The process goes like this, based on a set of YAML
files named in ``kind.yml``:

 * For each build task, determine the related test platforms based on the build
   platform.  For example, a Windows 2010 build might be tested on Windows 7
   and Windows 10.  Each test platform specifies a "test set" indicating which
   tests to run.  This is configured in the file named

 * Each test set is expanded to a list of tests to run.  This is configured in
   the file named by ``test-sets.yml``.

 * Each named test is looked up in the file named by ``tests.yml`` to find a
   test description.  This test description indicates what the test does, how
   it is reported to treeherder, and how to perform the test, all in a
   platform-independent fashion.

 * Each test description is converted into one or more tasks.  This is
   performed by a sequence of transforms defined in the ``transforms`` key in
   ``kind.yml``.  See :doc:`transforms`: for more information on these

 * The resulting tasks become a part of the task graph.

.. important::

    This process generates *all* test jobs, regardless of tree or try syntax.
    It is up to a later stage of the task-graph generation (the target set) to
    select the tests that will actually be performed.


The ``desktop-test`` kind defines tests for Desktop builds.  Its ``tests.yml``
defines the full suite of desktop tests and their particulars, leaving it to
the transforms to determine how those particulars apply to Linux, OS X, and


The ``android-test`` kind defines tests for Android builds.

It is very similar to ``desktop-test``, but the details of running the tests
differ substantially, so they are defined separately.


Tasks of the ``docker-image`` kind build the Docker images in which other
Docker tasks run.

The tasks to generate each docker image have predictable labels:

Docker images are built from subdirectories of ``taskcluster/docker``, using
``docker build``.  There is currently no capability for one Docker image to
depend on another in-tree docker image, without uploading the latter to a
Docker repository

The task definition used to create the image-building tasks is given in
``image.yml`` in the kind directory, and is interpreted as a :doc:`YAML
Template <yaml-templates>`.