Workflows: alternative task execution mechanism

[os-alan]

(this is the continuation of discussion of Workflow from #26)

@patriksvensson

I'm sorry if I sound negative, but it's so easy to add stuff and so difficult to remove them.

That's so true, and you sound pragmatic 😄

I can see a benefit from them if they respect task dependencies and criteria, which would make them a new kind of mechanism for task execution.

I also like the idea of workflows (so much, that I definitely going to implement them as POC at least in my fork 😄 ), but if they would respect Task's dependencies and conditions then there would be almost to difference to Targets (which is currently the only execution model).
The unique feature of the workflows (as I see them) is to allow user to declare dependencies and conditions on level of workflow itself, leaving tasks plain, simple and reusable in other workflows.

This way we could accomplish what you propose simply by not specifying dependencies or criteria for a task.

Looks like this is the way to go.
What if Workflow would work with existing Tasks, but will throw something like InvalidOperationException if it will detect any conditions or dependencies declared on them? This model would let us tick 2 checkboxes:

• Force user to use Workflow-style execution model (if his intention is to use Workflow)
• Do not introduce breaking changes to main execution model
• Do not introduce duplicate code (Jobs etc..)

This way, workflow model will be optional. And it is up to user to decide whether to stick with main model, or alternative.

What you think?

[devlead]

@os-alan any PoC done you want feedback on? Otherwise I'm going to go ahead and close this issue.

[os-alan]

@devlead No, unfortunately. Agree on closing the issue.