Taskgraph generation takes a collection of Parameters as input, in the form of a JSON or YAML file. Below are the parameters that Taskgraph supports.
Projects may define additional parameters on top of these ones.
These parameters describe metadata associated with the push that triggered the Decision Task.
The repository from which to do an initial clone.
The repository containing the changeset to be built. This may differ from
base_repositoryin cases where
base_repositoryis likely to be cached and only a few additional commits are needed from
The previous revision before
head_revgot merged into. This can be a short revision string.
The revision to check out, this can be a short revision string.
head_revgot merged into. It is usually a branch or a tag.
Reference that contains the
head_rev. It defaults to the current branch, then to the current revision if no branch is found.
The tag attached to the revision, if any.
Email address indicating the person who made the push. Note that this value may be forged and must not be relied on for authentication.
The ID from the
hg.mozilla.orgpushlog or 0.
The timestamp of the push to the repository that triggered this decision task. Expressed as an integer in seconds since the UNIX epoch.
The timestamp of the build date. Defaults to
pushdateand falls back to present time of taskgraph invocation. Expressed as an integer seconds since the UNIX epoch.
A formatted timestamp of
build_date. Expressed as a string with the following format: %Y%m%d%H%M%S
The type of repository, either
tasks_forvalue used to generate the decision task.
These parameters describe the “project” (or repository) that triggered the Decision Task.
Another name for what may otherwise be called repository. At Mozilla this may also be referred to as tree or branch. This is the unqualified name, such as
The SCM level associated with this tree.
These parameters are used at the
target_task phase of graph generation.
True, any task with the
always_targetattribute will be included in the
target_task_graphregardless of whether they were filtered out by the
target_tasks_methodor not. Because they are not part of the
target_set, they will still be eligible for optimization when the
List of filter functions (from
taskcluster/gecko_taskgraph/filter_tasks.py) to apply. This is usually defined internally, as filters are typically global.
The method to use to determine the target task set. This is the suffix of one of the functions in
These parameters are used at the
optimization phase of graph generation.
A Python path of the form
<module>:<object>pointing to a dictionary of optimization strategies to use, overwriting the defaults.
If true, then target tasks are eligible for optimization.
Specify tasks to not optimize out of the graph. This is a list of labels. Any tasks in the graph matching one of the labels will not be optimized out of the graph.
Specify tasks to optimize out of the graph. This is a dictionary of label to taskId. Any tasks in the graph matching one of the labels will use the previously-run taskId rather than submitting a new task.
These parameters are used by Mozilla’s code review bot.
The code review process needs to know the Phabricator Differential diff that started the analysis. This parameter must start with PHID-DIFF-
These parameters only apply when generating Taskgraph locally.
Generate only the given kind and its kind-dependencies. This is used for local inspection of the graph and is not supported at run-time.