Shared
ModelsExpand Collapse
AutomationTrigger { beforeSnapshot, manual, postDevcontainerStart, 3 more } An AutomationTrigger represents a trigger for an automation action.
The manual field shows a start button in the UI for manually triggering the automation.
The post_machine_start field indicates that the automation should be triggered after the machine has started, before the devcontainer is ready.
This is used for machine-level services like security agents that need to start early.
The post_environment_start field indicates that the automation should be triggered after the environment has started (devcontainer ready).
The post_devcontainer_start field indicates that the automation should be triggered after the dev container has started.
The prebuild field starts the automation during a prebuild of an environment. This phase does not have user secrets available.
The before_snapshot field triggers the automation after all prebuild tasks complete but before the snapshot is taken.
This is used for tasks that need to run last during prebuilds, such as IDE warmup.
Note: The before_snapshot trigger can only be used with tasks, not services.
An AutomationTrigger represents a trigger for an automation action.
The manual field shows a start button in the UI for manually triggering the automation.
The post_machine_start field indicates that the automation should be triggered after the machine has started, before the devcontainer is ready.
This is used for machine-level services like security agents that need to start early.
The post_environment_start field indicates that the automation should be triggered after the environment has started (devcontainer ready).
The post_devcontainer_start field indicates that the automation should be triggered after the dev container has started.
The prebuild field starts the automation during a prebuild of an environment. This phase does not have user secrets available.
The before_snapshot field triggers the automation after all prebuild tasks complete but before the snapshot is taken.
This is used for tasks that need to run last during prebuilds, such as IDE warmup.
Note: The before_snapshot trigger can only be used with tasks, not services.
EnvironmentClass { id, runnerId, configuration, 3 more }
Task { id, dependsOn, environmentId, 2 more }
description is a user-facing description for the task. It can be used to provide context and documentation for the task.
name is a user-facing name for the task. Unlike the reference, this field is not unique, and not referenced by the system. This is a short descriptive name for the task.
reference is a user-facing identifier for the task which must be unique on the environment. It is used to express dependencies between tasks, and to identify the task in user interactions (e.g. the CLI).
TaskExecution { id, metadata, spec, status }
desired_phase is the phase the task execution should be in. Used to stop a running task execution early.
desired_phase is the phase the task execution should be in. Used to stop a running task execution early.
plan?: Array<Plan>plan is a list of groups of steps. The steps in a group are executed concurrently, while the groups are executed sequentially.
The order of the groups is the order in which they are executed.
plan is a list of groups of steps. The steps in a group are executed concurrently, while the groups are executed sequentially. The order of the groups is the order in which they are executed.
failure_message summarises why the task execution failed to operate. If this is non-empty the task execution has failed to operate and will likely transition to a failed state.
log_url is the URL to the logs of the task’s steps. If this is empty, the task either has no logs or has not yet started.
version of the status update. Task executions themselves are unversioned, but their status has different versions. The value of this field has no semantic meaning (e.g. don’t interpret it as as a timestamp), but it can be used to impose a partial order. If a.status_version < b.status_version then a was the status before b.
steps?: Array<Step>steps provides the status for each individual step of the task execution. If a step is missing it
has not yet started.
steps provides the status for each individual step of the task execution. If a step is missing it has not yet started.
failure_message summarises why the step failed to operate. If this is non-empty the step has failed to operate and will likely transition to a failed state.
output contains the output of the task execution. setting an output field to empty string will unset it.
TaskExecutionSpec { desiredPhase, plan }
desired_phase is the phase the task execution should be in. Used to stop a running task execution early.
desired_phase is the phase the task execution should be in. Used to stop a running task execution early.
plan?: Array<Plan>plan is a list of groups of steps. The steps in a group are executed concurrently, while the groups are executed sequentially.
The order of the groups is the order in which they are executed.
plan is a list of groups of steps. The steps in a group are executed concurrently, while the groups are executed sequentially. The order of the groups is the order in which they are executed.
TaskExecutionStatus { failureMessage, logUrl, phase, 2 more }
failure_message summarises why the task execution failed to operate. If this is non-empty the task execution has failed to operate and will likely transition to a failed state.
log_url is the URL to the logs of the task’s steps. If this is empty, the task either has no logs or has not yet started.
version of the status update. Task executions themselves are unversioned, but their status has different versions. The value of this field has no semantic meaning (e.g. don’t interpret it as as a timestamp), but it can be used to impose a partial order. If a.status_version < b.status_version then a was the status before b.
steps?: Array<Step>steps provides the status for each individual step of the task execution. If a step is missing it
has not yet started.
steps provides the status for each individual step of the task execution. If a step is missing it has not yet started.
failure_message summarises why the step failed to operate. If this is non-empty the step has failed to operate and will likely transition to a failed state.
output contains the output of the task execution. setting an output field to empty string will unset it.
TaskMetadata { createdAt, creator, description, 3 more }
description is a user-facing description for the task. It can be used to provide context and documentation for the task.
name is a user-facing name for the task. Unlike the reference, this field is not unique, and not referenced by the system. This is a short descriptive name for the task.
reference is a user-facing identifier for the task which must be unique on the environment. It is used to express dependencies between tasks, and to identify the task in user interactions (e.g. the CLI).