Skip to content

v1.15.0

Compare
Choose a tag to compare
@kennyworkman kennyworkman released this 23 Aug 03:35
· 2194 commits to main since this release

This update introduces subworkflows and workflow references. These constructs allow for arbitrary composition of workflows within each other, enabling great organizational flexibility as well as reducing code duplication. Additionally, @mrland99 wrote docker build logs into the crash report if a workflow fails to register/build.

Subworkflow

To create a subworkflow, simply create two functions with the @workflow decorator and call one inside the other, as below:

@small_task
def this_is_a_sub_wf_task(a: int) -> int:
	print(“This is a sub-workflow”)
	return a + 1
  

@workflow
def this_is_a_sub_wf(b: int) -> int:
	return this_is_a_sub_wf_task(a=b)
  

@workflow
def this_is_a_top_level_wf(c: int) -> int:
	return this_is_a_sub_wf(b=c)

Workflow Reference

A reference workflow is distinct from a subworkflow in that a reference workflow is a reference to an existing workflow, meaning workflows are reusable in other workflows without duplicating code. To create a workflow reference, simply annotate an empty function with the @workflow_reference decorator as below.

@workflow_reference(
	name=“wf.__init__.assemble_and_sort”,
	version=“0.0.1”,
)


def assemble_and_sort(read1: LatchFile, read2: LatchFile):
	...

A few notes: the interface of the function must be the same as the workflow it is referencing. Moreover, the body of the function should be empty, and lastly, the version of the workflow being referenced must be available to the user in order to be referenced (i.e. you can’t reference a workflow you don’t have access to).

Docker Build Logs

See #119 - logs will automatically be found in $(pwd)/.logs and crash report tar. Thanks @mrland99.

Full Changelog: v1.14.1...v1.15.0