This repository has been archived by the owner on Jan 5, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 30
/
task.yml
191 lines (191 loc) · 7.34 KB
/
task.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
$schema: http://json-schema.org/draft-06/schema#
title: "Task Definition Response"
description: |
Definition of a task that can be scheduled
type: object
properties:
provisionerId:
title: "Provisioner Id"
description: |
Unique identifier for a provisioner, that can supply specified
`workerType`
type: string
minLength: {$const: identifier-min-length}
maxLength: {$const: identifier-max-length}
pattern: {$const: identifier-pattern}
workerType:
title: "Worker Type"
description: |
Unique identifier for a worker-type within a specific provisioner
type: string
minLength: {$const: identifier-min-length}
maxLength: {$const: identifier-max-length}
pattern: {$const: identifier-pattern}
schedulerId:
title: "Scheduler Identifier"
description: |
Identifier for the scheduler that _defined_ this task, this can be an
identifier for a user or a service like the `"task-graph-scheduler"`.
Along with the `taskGroupId` this is used to form the permission scope
`queue:assume:scheduler-id:<schedulerId>/<taskGroupId>`,
this scope is necessary to _schedule_ a defined task, or _rerun_ a task.
type: string
minLength: {$const: identifier-min-length}
maxLength: {$const: identifier-max-length}
pattern: {$const: identifier-pattern}
taskGroupId:
title: "Task-Group Identifier"
description: |
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.
type: string
pattern: {$const: slugid-pattern}
dependencies:
title: "Task Dependencies"
description: |
List of dependent tasks. These must either be _completed_ or _resolved_
before this task is scheduled. See `requires` for semantics.
type: array
items:
title: "Task Dependency"
description: |
The `taskId` of a task that must be resolved before this task is
scheduled.
type: string
pattern: {$const: slugid-pattern}
maxItems: {$const: max-task-dependencies}
uniqueItems: true
requires:
title: "Dependency Requirement Semantics"
description: |
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.
type: string
enum: {$const: dependency-relation}
routes:
title: "Task Specific Routes"
description: |
List of task specific routes, AMQP messages will be CC'ed to these routes.
type: array
items:
title: "Task Specific Route"
description: |
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](http://www.rabbitmq.com/tutorials/tutorial-five-python.html)
for examples on how to use routing-keys.
type: string
maxLength: 249
minLength: 1
maxItems: 64
uniqueItems: true
priority:
title: "Task Priority"
description: |
Priority of task, this defaults to `lowest` and the scope
`queue:create-task:<priority>/<provisionerId>/<workerType>` is required
to define a task with `<priority>`.
type: string
enum:
- highest
- very-high
- high
- medium
- low
- very-low
- lowest
retries:
title: "Retries"
description: |
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.
type: integer
minimum: 0
maximum: 49
created: {$const: created}
deadline: {$const: deadline}
expires:
title: "Expiration"
description: |
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).
type: string
format: date-time
scopes:
title: "Scopes"
description: |
List of scopes (or scope-patterns) that the task is
authorized to use.
type: array
items:
title: "Scope"
description: |
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.
type: string
pattern: {$const: scope-pattern}
payload:
title: "Task Payload"
description: |
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.
type: object
metadata: {$ref: "http://schemas.taskcluster.net/queue/v1/task-metadata.json#"}
tags:
title: "Tags"
description: |
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.
type: object
additionalProperties:
type: string
maxLength: 4096
extra:
title: "Extra Data"
description: |
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.
type: object
default: {}
additionalProperties: false
required:
- provisionerId
- workerType
- schedulerId
- taskGroupId
- dependencies
- requires
- routes
- priority
- retries
- created
- deadline
- scopes
- payload
- metadata
- tags
- extra