Get desktop application:
View/edit binary Protocol Buffers messages
WorkflowService exposes various capabilities when it comes to starting and monitoring a workflow
WorkflowContext represents the state of the execution of this workflow in detail. How many tasks are currently executed, the number of actions and their state.
The workflow ID
the name of the current action
The index of the current action
The state of the current action
WorkflowActionsRequest is used to get actions for a particular workflow
A list of actions
WorkflowActionStatus represents the state of all the action part of a workflow
The workflow id
The name of the task this action is part of
The name of the action
The state of the action. Those are the same described for workflow as well. pending, running, successful and so on.
The execution time for the action
The message returned from the action.
When the status got created for this aciton. You can see it as the time when the action started its execution inside the hardware itself.
(message has no fields)
The various state a workflow can be
Used in:
,A workflow is in pending state when it is waiting for the hardware to pick it up and start the execution.
A workflow is in a running state when the tink-worker started the exeuction of it, and it is currently in execution inside the device itself.
Failed is a final state. Something wrong happened during the execution of the workflow inside the target. Have a look at the logs to see if you can spot what is going on.
Timeout is final state, almost like FAILED but it communicate to you that an action or the overall workflow reached the specified timeout.
This is the state we all deserve. The execution of the workflow is over and everything is just fine. Sit down, and enjoy your great work.
WorkflowAction represents a single aciton part of a workflow
Used in:
The name of the task the action belong to.
The name of the action
The docker/oci image the action starts from
Every action has a timeout, after that the execution stops and the action gets in a timeout state.
You can override the command executed for the container
On timeout used to be a way to execute an action if the current one times out but with the event system in place this is not needed anymore
On failure used to be a way to execute an action if the current one fails but with the event system in place this is not needed anymore
You can mount directory from your host to the running action, mainly to share files, or state
Set environment variables usable from the action itself.
Set the namespace that the process IDs will be in.