- Comments: #75
- Initially Proposed by: @djmitche
The Taskcluster team recommends use of dummy tasks for various purposes, and release engineering has also found them useful for various unusually-behaved tasks.
- sending a message or being able to check when some subset of a task group is complete (e.g., all windows builds)
- "faking out" production-only tasks when making development or staging task graphs (e.g., replace the balrog update task with
built-in/succeed)
Taskcluster should supply a collection of special-cased workerTypes with
simple, predefined, useful behaviors, gathered under the built-in provisionerId [*].
-
built-in/succeed-- When a task of this worker type is scheduled, it is immediately resolved as successful. -
built-in/fail-- When a task of this worker type is scheduled, it is immediately resolved as failed.
Scopes for these workerTypes would be given to assume:repo:*. Since the tasks do not do anything interesting, store any potentially-compromisable state, or allow pending tasks, everyone can share the same workerTypes.
[*] this is treating provisionerId as something closer to "workerTypeGroup", since there is no provisioner service associated with this provisionerId.