-
Notifications
You must be signed in to change notification settings - Fork 163
Description
Output.from expression indicates the result of the task (and can be consumed by subsequent task)
Output.to expression indicates what should be the value of the context once the task is completed.
I think the names are confusing (it actually takes me a lot of time to understand why do we have two expressions in output), so I think we must change them.
output.from might be renamed to output.result (the expression indicates the result of the task)
output.to might be renamed to output.setContext (clearly states the purpose is to the set the value of the context), If we found that setContext break the single word paradigm that we are implicitly following in the DSL, then lets just use output.context.
Also we need to explicilly indicate in the documentation that it is assumed that the expression language should support merging context.
Related to that, if this assumption turns to be wrong, another possibility is to use
output:
context:
set:
Right now, context will only support set: but we leave the door open to add append:, delete: or merge: in future if needed
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Activity
cdavernas commentedon Jun 6, 2024
@JBBianchi @matthias-pichler-warrify WDYT?
output.from
tooutput.result
output.to
tooutput.context
Personally:
JBBianchi commentedon Jun 6, 2024
Globally, more documentation won't hurt, for sure :)
If I can add my grain of salt, we might gain clarity by "splitting"
output.from
andoutput.to
into distinct keywords. So my take would be the following:output.from
tooutput
, it shows the intention of the user to alter/transform the default output (but I have no strong opinion)output.to
toexport
, it shows the intention of the user to export something from the task to a broader context (but again, I have no strong opinion)cdavernas commentedon Jun 6, 2024
You suggestion is awesome! Much clearer and ubiquitous!
This would however get rid of the critical
output.schema
property, as discussed in #837 😭We could however move it elsewhere. Ideas?
JBBianchi commentedon Jun 6, 2024
Good catch, I didn't think about that ... We could keep the
to
then maybe ? (oras
)fjtirado commentedon Jun 6, 2024
The problem with to is that it might user though they can set the destination, which is not really true, so I vote for
as
rather thanto
.I was going to suggest the same split than @JBBianchi ;)
Also, using export: as a separate keyword allow us to add in future set: or merge: if we change our mind.
cdavernas commentedon Jun 6, 2024
Works for me!
Even though I'm not opposed to using
as
, it doesn't, IMHO, carry the idea of a 'transformation', which is what the expression is used for in the context of theoutput
.On a side note, there is not way to specify the
context
schema, but I get its was a copy/paste leftover.Should therefore be:
Or, if we believe we might need additional properties at some point, like @fjtirado said:
JBBianchi commentedon Jun 6, 2024
It was intentional, why can't we support a schema for the context as well ? I think it's a point that's been raised, even in the previous version of the spec, that we don't know at some point in the workflow, what to expect in the context. With the schema, it give the opportunity to the user to defined what expected of the context to be at a given point in time.
cdavernas commentedon Jun 6, 2024
@JBBianchi because you cannot forecast the state of the context (ex: if a switch state was executed before) at a point in time.
AFAIK, that never was brought up, also because you can both update the context (adding a new prop, removing one, etc) and replace it. For the replace it could work but has little to no value. For the update, that would be impossible or at least impractical (diff patch or replace), for little to no value.
IMO there's no way you, or any user, would like to document a whole schema just for updating a prop in a data bag (unordered, untyped).
fjtirado commentedon Jun 6, 2024
@cdavernas I can foresee schema for context being used by users that want to restrict the context content (I do agree with you that the most frequent use case is "free" context ;)). As far as is optional I do not see any issue.
11 remaining items