Task Schema

Task Definition

The following is the JSON schema for a task definition:

Task Definition Request (source)

Definition of a task that can be scheduled


Unique identifier for a provisioner, that can supply specified workerType


Unique identifier for a worker-type within a specific provisioner

default: -

Identifier for the scheduler that defined this task, this can be an identifier for a user or a service like the "task-graph-scheduler". Task submitter required scopes queue:assume:scheduler-id:<schedulerId>/<taskGroupId>. This scope is also necessary to schedule a defined task, or rerun a task.


Identifier for a group of tasks scheduled together with this task, by scheduler identified by schedulerId. For tasks scheduled by the task-graph scheduler, this is the taskGraphId. Defaults to taskId if property isn't specified.

dependenciesArray of[0:100]

List of dependent tasks. These must either be completed or resolved before this task is scheduled. See requires for semantics.

Task Dependencystring^[A-Za-z0-9_-]{8}[Q-T][A-Za-z0-9_-][CGKOSWaeimquy26-][A-Za-z0-9_-]{10}[AQgw]$

The taskId of a task that must be resolved before this task is scheduled.

default: all-completed
  • all-completed
  • all-resolved

The tasks relation to its dependencies. This property specifies the semantics of the task.dependencies property. If all-completed is given the task will be scheduled when all dependencies are resolved completed (successful resolution). If all-resolved is given the task will be scheduled when all dependencies have been resolved, regardless of what their resolution is.

routesArray of[0:64]

List of task specific routes, AMQP messages will be CC'ed to these routes. Task submitter required scopes queue:route:<route> for each route given.

Task Specific Routestring[1:249]

A task specific route, AMQP messages will be CC'ed with a routing key matching route.<task-specific route>. It's possible to dot (.) in the task specific route to make sub-keys, etc. See the RabbitMQ tutorial for examples on how to use routing-keys.

default: lowest
  • highest
  • very-high
  • high
  • medium
  • low
  • very-low
  • lowest
  • normal

Priority of task, this defaults to lowest, equivalent to the deprecated normal. Task submitter required scopes queue:task-priority:high for high priority tasks.

default: 5

Number of times to retry the task in case of infrastructure issues. An infrastructure issue is a worker node that crashes or is shutdown, these events are to be expected.


Creation time of task


Deadline of the task, pending and running runs are resolved as exception if not resolved by other means before the deadline. Note, deadline cannot be more than 5 days into the future


Task expiration, time at which task definition and status is deleted. Notice that all artifacts for the task must have an expiration that is no later than this. If this property isn't it will be set to deadline plus one year (this default may subject to change).

scopesArray of

List of scopes (or scope-patterns) that the task is authorized to use.


A scope (or scope-patterns) which the task is authorized to use. This can be a string or a string ending with * which will authorize all scopes for which the string is a prefix. Scopes must be composed of printable ASCII characters and spaces. Task submitter required scopes The same scope-pattern(s) given (otherwise a task could be submitted to perform an action that the task submitter is not authorized to perform).

payloadObject of

Task-specific payload following worker-specific format. For example the docker-worker requires keys like: image, commands and features. Refer to the documentation of docker-worker for details.

Anything ¯\_(ツ)_/¯
metadataObject of

Required task metadata


Human readable name of task, used to very briefly given an idea about what the task does.


Human readable description of the task, please explain what the task does. A few lines of documentation is not going to hurt you.


E-mail of person who caused this task, e.g. the person who did hg push. The person we should contact to ask why this task is here.


Link to source of this task, should specify a file, revision and repository. This should be place someone can go an do a git/hg blame to who came up with recipe for this task.

tagsObject of
default: [object Object]

Arbitrary key-value tags (only strings limited to 4k). These can be used to attach informal metadata to a task. Use this for informal tags that tasks can be classified by. You can also think of strings here as candidates for formal metadata. Something like purpose: 'build' || 'test' is a good example.

extraObject of
default: [object Object]

Object with properties that can hold any kind of extra data that should be associated with the task. This can be data for the task which doesn't fit into payload, or it can supplementary data for use in services listening for events from this task. For example this could be details to display on treeherder, or information for indexing the task. Please, try to put all related information under one property, so extra data keys for treeherder reporting and task indexing don't conflict, hence, we have reusable services. Warning, do not stuff large data-sets in here, task definitions should not take-up multiple MiBs.

Anything ¯\_(ツ)_/¯