зеркало из https://github.com/mozilla/gecko-dev.git
210 строки
7.1 KiB
ReStructuredText
210 строки
7.1 KiB
ReStructuredText
Task Kinds
|
|
==========
|
|
|
|
This section lists and documents the available task kinds.
|
|
|
|
build
|
|
------
|
|
|
|
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.
|
|
|
|
build-signing
|
|
--------------
|
|
|
|
|
|
artifact-build
|
|
--------------
|
|
|
|
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
|
|
------
|
|
|
|
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.
|
|
|
|
l10n
|
|
----
|
|
|
|
The l10n kind takes the last published nightly build, and generates localized builds
|
|
from it. You can read more about how to trigger these on the `wiki
|
|
<https://wiki.mozilla.org/ReleaseEngineering/TryServer#Desktop_l10n_jobs_.28on_Taskcluster.29>`_.
|
|
|
|
nightly-l10n
|
|
------------
|
|
|
|
The nightly l10n kind repacks a specific nightly build (from the same source code)
|
|
in order to provide localized versions of the same source.
|
|
|
|
nightly-l10n-signing
|
|
--------------------
|
|
|
|
The nightly l10n signing kind takes artifacts from the nightly-l10n kind and
|
|
passes them to signing servers to have their contents signed appropriately, based
|
|
on an appropriate signing format. One signing job is created for each nightly-l10n
|
|
job (usually chunked).
|
|
|
|
source-test
|
|
------------
|
|
|
|
Source-tests are tasks that run directly from the Gecko source. This can include linting,
|
|
unit tests, source-code analysis, or measurement work. While source-test tasks run from
|
|
a source checkout, it is still possible for them to depend on a build artifact, though
|
|
often they do not.
|
|
|
|
upload-symbols
|
|
--------------
|
|
|
|
Upload-symbols tasks run after builds and upload the symbols files generated by
|
|
build tasks to Socorro for later use in crash analysis.
|
|
|
|
valgrind
|
|
--------
|
|
|
|
Valgrind tasks produce builds instrumented by valgrind.
|
|
|
|
static-analysis
|
|
---------------
|
|
|
|
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
|
|
artifact.
|
|
|
|
toolchain
|
|
---------
|
|
|
|
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
|
|
------------
|
|
|
|
Spidermonkey tasks check out the full gecko source tree, then compile only the
|
|
spidermonkey portion. Each task runs specific tests after the build.
|
|
|
|
Tests
|
|
-----
|
|
|
|
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 "test sets" indicating which
|
|
tests to run. This is configured in the file named
|
|
``test-platforms.yml``.
|
|
|
|
* Each test set is expanded to a list of tests to run. This is configured in
|
|
the file named by ``test-sets.yml``. A platform may specify several test
|
|
sets, in which case the union of those sets is used.
|
|
|
|
* 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
|
|
transforms.
|
|
|
|
* 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.
|
|
|
|
test
|
|
....
|
|
|
|
The ``desktop-test`` kind defines tests for 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 the various platforms.
|
|
|
|
This kind includes both unit tests and talos.
|
|
|
|
docker-image
|
|
------------
|
|
|
|
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:
|
|
``build-docker-image-<name>``.
|
|
|
|
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>`.
|
|
|
|
android-stuff
|
|
--------------
|
|
|
|
balrog
|
|
------
|
|
|
|
Balrog is the Mozilla Update Server. Jobs of this kind are submitting information
|
|
which assists in telling Firefox that an update is available for the related job.
|
|
|
|
balrog-l10n
|
|
-----------
|
|
|
|
Balrog is the Mozilla Update Server. Jobs of this kind are submitting information
|
|
which assists in telling Firefox that an update is available for the localized
|
|
job involved.
|
|
|
|
beetmover
|
|
---------
|
|
|
|
Beetmover, takes specific artifacts, "Beets", and pushes them to a location outside
|
|
of Taskcluster's task artifacts, (archive.mozilla.org as one place) and in the
|
|
process determines the final location and a "pretty" name (versioned product name)
|
|
|
|
beetmover-l10n
|
|
--------------
|
|
|
|
Beetmover L10n, takes specific artifacts, "Beets", and pushes them to a location outside
|
|
of Taskcluster's task artifacts, (archive.mozilla.org as one place) and in the
|
|
process determines the final location and a "pretty" name (versioned product name)
|
|
This separate kind uses logic specific to localized artifacts, such as including
|
|
the language in the final artifact names.
|
|
|
|
checksums-signing
|
|
----------------
|
|
Checksums-signing take as input the checksums file generated by beetmover tasks
|
|
and sign it via the signing scriptworkers. Returns the same file signed and
|
|
additional detached signature.
|
|
|
|
beetmover-checksums
|
|
-------------------
|
|
Beetmover, takes specific artifact checksums and pushes it to a location outside
|
|
of Taskcluster's task artifacts (archive.mozilla.org as one place) and in the
|
|
process determines the final location and "pretty" names it (version product name)
|
|
|
|
push-apk-breakpoint
|
|
-------------------
|
|
Decides whether or not APKs should be published onto Google Play Store. Jobs of this
|
|
kind depend on all the signed multi-locales (aka "multi") APKs for a given release,
|
|
in order to make the decision.
|
|
|
|
push-apk
|
|
--------
|
|
PushApk publishes Android packages onto Google Play Store. Jobs of this kind take
|
|
all the signed multi-locales (aka "multi") APKs for a given release and upload them
|
|
all at once. They also depend on the breakpoint.
|