Version 0.6 has been released. Most of the updates are focussed around improvements to the UI, but a notable (though subtle) behavioural addition is the concept of 'spawning'.

Spawned runs

This release introduces the concept of 'spawned' runs.

Previously, when a step called another workflow, this would automatically start a new run for that workflow. This made sense most of the time, but a notable exception is when a cached result for the workflow can be used - in that case it's a bit confusing that a new run gets created.

With the change introduced in this release, the call to the second workflow is always represented by a step in the initial run. This means the cache lookup is done inside the initial run, so a separate run is only created when needed. Re-running the step in the parent run will create another run (ignoring the cache); re-running the step in the child run will re-run only that run. This behaviour should feel more consistent and be more intuitive.

For example, the following code shows my_workflow calling cached_workflow.

@cf.workflow(cache=True)
def cached_workflow():
    ...

@cf.workflow()
def my_workflow():
    return cached_workflow()

In the UI, when my_workflow is run (with cached_workflow having previously been run) you can see the icon indicating a cache hit, and a reference to easily navigate to the cached run:

With this change the mechanism for cache lookups in general is deferred, which means that any configured delays are taken into account before looking for a cached result.

Search

The UI now includes a search box (that can be accessed using Ctrl-K). It supports searching for workflows/sensors and tasks - taking you to the latest run where possible.

Step freshness

If a step depends on the result from a step that has since been re-run, it is considered 'stale', and this is now indicated more clearly in the UI, encouraging you to re-run the step if needed.

In the example below, task_a has been manually re-run. Since the my_workflow step depended on the result, it is marked as 'stale':

Archiving repositories

The sidebar accumulates the latest set of workflows for each repository. This means that if a repository is renamed or removed it will remain in the sidebar. This release adds the ability to 'archive' a repository so that it's hidden (until it's re-registered).

Workflow instructions

If present, the docstring of workflow (or sensor) is included in the manifest during registration, and then displayed in the run dialog in the UI. This is a great place to document what the workflow does:

Cancelling executions from tasks

Tasks (or workflow/sensors) that have been submitted can now be cancelled programmatically. For example:

@cf.workflow()
def my_workflow():
    execution = my_task.submit()
    sleep(0.2)
    execution.cancel()  # 👈

See the documentation here.