While provides more self-contained tasks, for simple use cases it might be more straightforward to allow for forward dependencies.
myTask:
...
on-complete:
- nextTask1
- nextTask2
On the backend the dependencies should resolve similarly: a task waits for all dependencies, whether specified forward or backward, to resolve. dependencyAwait allows tasks to wait for only a part of their dependencies. However, with the constraint that individual tasks can only be invoked once, this means that you can only create discriminators not 'multiple instances' (see http://workflowpatterns.com/).
Similar to Openstack's mistral, we can support both. The user should be able to specify which type of dependency definition they want to use.
Currently workflows are defined using a backward dependencies. For example:
While provides more self-contained tasks, for simple use cases it might be more straightforward to allow for forward dependencies.
On the backend the dependencies should resolve similarly: a task waits for all dependencies, whether specified forward or backward, to resolve.
dependencyAwait
allows tasks to wait for only a part of their dependencies. However, with the constraint that individual tasks can only be invoked once, this means that you can only create discriminators not 'multiple instances' (see http://workflowpatterns.com/).Similar to Openstack's mistral, we can support both. The user should be able to specify which type of dependency definition they want to use.
The default, though open for discussion, would be backward.