Polymorphism for workflows and actions

Registered by Renat Akhmerov

The idea is to treat actions and workflows uniformly when defining tasks. From a task perspective there shouldn't be any differences between an action and a workflow. As long as they take defined set of parameters and implement required logic they can be called. So in this sense we can talk about polymorphic behavior regarding tasks and workflows.

Think of different options to implement this:
- call subworkflow via the same REST API (recursive API call)
- drop a message into a workflow queue

This requirement may leads to the need to define workflows themselves differently. First of all, they need to have explicitly declared input parameters and output in a similar way to what actions have.

Blueprint information

Status:
Complete
Approver:
Renat Akhmerov
Priority:
High
Drafter:
Renat Akhmerov
Direction:
Needs approval
Assignee:
Renat Akhmerov
Definition:
New
Series goal:
Accepted for juno
Implementation:
Implemented
Milestone target:
milestone icon 0.1
Started by
Renat Akhmerov
Completed by
Renat Akhmerov

Related branches

Sprints

Whiteboard

At first stage, I think we should deny calling the same workflow from itself (recursion).

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.