Specification#

Workflow#

Field Name	Type	Required	Description
`name`	`string`	Yes	The name of the workflow.
`pool`	`string`	No	The pool to submit the workflow to.
`labels`	`dict`	No	Immutable workflow metadata copied to every task pod. See Workflow Labels.
`timeout`	`dict`	No	Timeout configuration
`resources`	`dict`	No	Dictionary of resource specifications
`tasks`	`list`	Yes (or `groups`)	List of task definitions.
`groups`	`list`	Yes (or `tasks`)	List of group definitions.

Workflow Labels#

Labels identify a workflow independently of mutable tags. Keys and values use Kubernetes label syntax, values must be non-empty, and a workflow can define at most 16 labels. Labels are stored with the submitted specification and copied only to task pods, not to Services, Secrets, scheduler groups, or other objects. Any syntactically valid key is accepted; where a workflow label collides with a system-owned pod label (the osmo. selectors or scheduler queue labels), the system value wins on the pod.

workflow:
  name: training
  labels:
    team: robotics
    experiment: run42
  tasks:
  - name: train
    image: ubuntu:24.04
    command: [bash]
    args: [-lc, "echo training"]

Your administrator may configure particular keys in off, warn, or enforce mode. A submission can succeed and still print a warning while an administrator is rolling out a requirement. Use Workflow Submission to validate and override labels without editing a shared specification.

Task#

Field Name	Type	Required	Description
`name`	`string`	Yes	The name of the task (unique within the workflow).
`image`	`string`	Yes	The container image registry and image tag, ex: `ubuntu:22.04`
`lead`	`boolean`	No	The group leader designation of the task. Only applicable if the task is part of a Group.
`command`	`list`	Yes	The command to run in the container.
`args`	`list`	No	The arguments to pass to the command.
`environment`	`dict`	No	The environment variables to set in the container.
`credentials`	`dict`	No	The credentials to inject into the container. See Secrets for more information.
`inputs`	`list`	No	The inputs to download into the task container. See Inputs for more information.
`outputs`	`list`	No	The outputs to upload after completion. See Outputs for more information.
`files`	`list`	No	The files to mount into the task container. See File Injection for more information.
`resource`	`string`	No	Reference to the `resources` spec defined at the workflow level.
`volumeMounts`	`list`	No	The volumes to mount into the task container. See Host Mounts for more information.
`exitActions`	`dict`	No	The exit actions to perform after the task terminates. See Exit Actions for more information.
`checkpoint`	`list`	No	The checkpoint specifications to use for this task. See Checkpointing for more information.
`privileged`	`boolean`	No	The privileged mode setting that grants containers nearly unrestricted access to the host system. Note Please consult your administrator to enable this feature.
`hostNetwork`	`boolean`	No	The task pod host network setting that allows a pod to use the host node’s network namespace instead of having its own isolated network stack. Note Please consult your administrator to enable this feature.

Group#

Field Name	Type	Required	Description
`name`	`string`	Yes	The name of the group (unique within the workflow).
`barrier`	`boolean`	No	Default is `true`. When enabled, the tasks in the group will be synchronized and execution will start only when all tasks in the group are ready. See Barriers for more information.
`ignoreNonleadStatus`	`boolean`	No	Default is `true`. When set to `true`, a failure of a non-lead task will not cause the group to fail. When set to `false`, the group will fail if any task (lead or non-lead) fails. Note When a task gets rescheduled, the other tasks in the group continue running. If you want the other tasks to be restarted, please set `ignoreNonleadStatus` to `false`. Learn more at Group Lifecycle.
`tasks`	`list`	Yes	The list of tasks in the group. See Task for more information. Important Each group must have 1 lead task.