Scripts & Tasks
CUE’s scripting layer is built on top of tools/flow . In this area, you can define tasks with CUE which interact with the outside world. In other words, where non-hermetic operations are allowed.
cue/flow can automatically infer task dependencies
based on references between their values.
Tasks, where all tasks it dependens have on have completed,
are available to run.
But what happens when there is no dependency, yet the order is important?
The above code may or may not have this output, as both tasks are available to run and the script is non-deterministic.
When this situation arises,
we need to tell
a dependency between the tasks exists
by making an explicit reference.
This is like “using” the output from a first task
in the second task, but actually ignoring the output.
This new version, with
$dep: mkdir.$done is
guaranteed to have consistent and correct order.
Another common pattern in scripting and tasks are
- running tasks for each entry in a list or map
- conditionally running a task
We can use CUE’s comprehenesion capabilities for both of these, even together.
Sequential Comprehended Tasks
What if we combine the last two examples?
- The comprehended tasks would run in parallel
- We actually want them to run sequentially
We can conditionally refer to the previous task as follows:
Scripts with args
We can use the
as a way to inject values or args
when running a script.
cue cmd -t msg=foobar print args_tool.cue
Reusable Scripts and Tasks
We can define reusable tasks, though some extra care is needed when using them. Additionally we can create values containing many tasks and even import them.
The follow does not work because we reference a single field
within the task, but never the full task value.
cue cmd only runs tasks which are eventually nested under
the root value of the command you run.
To fix this, we use localized references to add the task within the task to run. Note, this can be used to import tasks which import tasks, ad infinitum, as long as every task has localized references to the tasks it depends on.
Importing tasks works around two things:
_tool.cuefiles cannot be imported
- tasks packages can only be imported in
Instead, we code with care and
- Put reusable tasks in regulare
- Skip importing the packages and schemas
- Use the
$idfield and ensure the other fields are correct
At Hofstadter, we are building a custom task engine on
It adds task analytics, visualization, distributability,
and many additional task types.
- [docs tbd…] see the following for now