St2: Orquesta should allow publishing of all the intermediate task results and published variables

[Kami]

Right now Orquesta doesn't include intermediate task results and published variables in the result attribute and st2 execution get <id> -d command output which makes developing and debugging Orquesta workflows slow and not fun.

In action-chain and mistral-v2 runner we already have display_published runner level parameter which makes it include published variables in the result output.

In addition to that, Mistral already includes all that info in result attribute. The problem with Mistral is that it's too noisy so we should find some kind of balance (aka only publish task results and variables when some runner parameter is set or similar).

NOTE: I created this issue on this repo and not StackStorm/orquesta, because I believe that's primary a feature of the Orquesta StackStorm runner. If we will need additional features and / or changes in orquesta repo, we can open corresponding issues there as well.

[nmaludy]

+1 We currently struggle with the lack of this feature. What i would like to see is:

• The inputs of each task (even core.noop tasks would be a nice to have)
• The outputs (published variables) from each task so we can debug actions and transitions
• Potentially see "paths" / "flows" taken in the workflow.

[nmaludy]

Another usecase for this is to inspect the output of the expressions in the when clauses of the next transitions.

I've helped 3x people this week on Slack because their when clauses had logic errors in them causing them to always evaluate to True. Example: one person had a transition of:

next:
  - when: <% succeeded %>
    do:
      - xyz

Because succeeded is a string in this case and not the function succeeded() it caused that transition path to always be taken.

I had a similar error with two other people earlier this week and they couldn't debug this problem because they couldn't see what the result of their expression was evaluating to.

[m4dcoder]

@nmaludy There are two different issues here. The first is the ability to see runtime information on the workflow execution which includes input, output, and transition. The second is detection of logic errors in when of task transition where users are stumbling on the expression and assuming they can combine more than one expressions with literal and. Let's open a separate issue for the latter because we can address that in WF inspection before the WF is executed and don't allow it and let users know that the result of combining more than one expressions with a literal and can result in a string which results in the expression begin evaluated to True all the time.

[nmaludy]

I'll happily open up another issue, but i think seeing the when expression evaluations would be beneficial for debugging too

[m4dcoder]

Thanks. Please open the separate issue. I agree that the solution for this issue, where and when it gets implemented, should include information about task transition and result of the expression evaluation.

[xod442]

+1 I have been struggling with this for a couple days, I see output from my action but I don't know how ctx() is storing it. (string,array, or object)

[nmaludy]

@punkrokk FYI you would need to wait for this if you want to get access to the published variables in Orquesta

[guzzijones]

I suppose a workaround would be to echo ctx() for now using a bash action. If we xould see the ending ctx that alone would help.