Currently, tasks are either "build" or "test" tasks. And "test" tasks
are dependent on "build" tasks, so they are effectively an extension of
"build" tasks.
Not everything is a "build" task. Not everything is associated with a
specific platform.
This commit introduces support for defining non-build "tasks" under the
"tasks" top-level element of a jobs YAML file. Interally, they are
treated as "build" tasks but are declared differently.
By default, all these tasks run.
The -j/--job argument has been added to the try syntax parser. It
specifies an opt-in list of these non-build tasks to run. By default, it
runs all of them.
The eslint-gecko "build" task has been moved to this new mechanism.
Documentation for the new task type have been added.
There is definitely some wonkiness in this implementation. For example,
there are references to "build_name," "build_type," and "build_product,"
which arguably are no longer relevant to generic tasks. However, they
appear to be so integrated into task processing (including route names)
that I'm a bit scared to change them.
MozReview-Commit-ID: BY219tLFb6Z
This adds a lot of functionality to the `flags.aliases` field in the try
comment parser, and implements all of the aliases currently supported by
Buildbot's try_parser.py.
The situation changes slightly because of the way chunks are handled; it's no
longer possible to specify chunks using an alias with no leading `-`. This
change should not cause undue hardship.
taskcluster-graph and taskcluster-build mach command now has the
--interactive option and try supports the "-i" flag.
This makes all tasks interactive.
Emulator tasks have some additional parameters not found in other
tasks. Therefore, builds can have an 'additional-parameters' field in
which specific task template replacements can be passed to trygraph.
This field is optional.
Moreover, the syntax for job_flags.yml builds was changed a bit.
Now, instead of:
builds:
<platform>:
types:
opt: <task>
debug: <task>
The syntax is:
builds:
<platform>:
types:
opt:
task: <task>
additional-parameters:
<parameter 1>: <value>
<parameter 2>: <value>
...
debug:
task: <task>
additional-parameters:
<parameter 1>: <value>
<parameter 2>: <value>
...