TEP-0156 : when-in-steps #1147
TEP-0156 : when-in-steps #1147
Conversation
tekton-robot
added
the
size/L
ericzzzzzzz
force-pushed
the
step-when
branch
3 times, most recently
from
42b9464
to
f841b49
Compare
tekton-robot
added
the
kind/tep
|
/kind tep |
|
/assign |
teps/0155-whenexpressions-in-step.md
Outdated
|
|
||
| ### Supported Expression Languages | ||
|
|
||
| Just like when expressions in Task Level, when expressions in Step Level will also be supporting both Operator-based expressions and CEL(Common Expression Language) expressions. |
There was a problem hiding this comment.
May be also add a paragraph on which fields are we applying when expressions on?
- all task based fields(e.g. Task Results, Task Conditions etc.)
- Workspaces
- Params
- StepResults
- StepStatus(?):
TerminationReasonFields: Error, Continued, Skipped, TimeOut, Cancelled etc.
There was a problem hiding this comment.
I added a Variable Substitution section to explains which fields can be referenced in step.when.
StepStatus(?)
It seems that we haven't StepStatus implemented yet, should we include in this tep? This seems a different scope.
There was a problem hiding this comment.
I'm ok keeping it out for now.
There was a problem hiding this comment.
IMHO, we should include some way to allow conditional execution on step status. Otherwise usage of When expression in guarding a step will be limited. I think one major advantage of a When expression guarding a step is to check the status of preview steps. Otherwise we are forcing the user to "mimic" this functionality by exporting a pseudo status of step to workspace/result to mimic this functionality.
Secondly, is it possible to check attributes of files in a workspace in When expressions?
There was a problem hiding this comment.
Hi, @haroonc
Thanks for the review! I've added step status variable substitution when evaluating When expressions in the design.
For checking file attributes, as far as i know Tekton doesn't support that directly. But, you can use a script in a step to get attributes and store them as results. Then, use those results in When expressions in later steps.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chitrangpatel The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
tekton-robot
added
the
approved
|
@ericzzzzzzz can you please leave a short description of the TEP in the opening comment? |
|
@tektoncd/core-maintainers PTAL 🙏 |
done! Thanks |
|
/assign |
tekton-robot
added
the
needs-rebase
tekton-robot
removed
the
needs-rebase
ericzzzzzzz
force-pushed
the
step-when
branch
4 times, most recently
from
7ca83ad
to
7b6f7d5
Compare
|
/assign @vdemeester |
| - End-to-end tests covering common use cases and error conditions. | ||
|
|
||
| ## Alternatives | ||
| An alternative approach would be to evaluate When Expressions before creating the pods for the steps. If a When Expression evaluates to false, the corresponding step container would not be created at all. |
There was a problem hiding this comment.
I think you meant creating step containers inside the pods for the Task. There are no pods for containers.
There was a problem hiding this comment.
I meant tekton can evaluate 'when expressions' when building pod definition, if the evaluation result is false, then we don't have to add the corresponding step container to the pod 'spec.containers'
| ## Motivation | ||
| Currently, Tekton Tasks execute steps sequentially without the ability to control their execution based on conditions within the Task itself. This limitation restricts the ability to create dynamic workflows that adapt to different scenarios or respond to the outcomes of previous steps. | ||
| By introducing When Expressions to Steps, users will be able to: | ||
| - **Create conditional workflows**: Execute steps only when specific conditions are met, such as the success or failure of a previous step, the value of a result, or the presence of a specific parameter. |
There was a problem hiding this comment.
Related with this: the new v2alpha4 formatter from Tekton Chains now is processing all the type-hinted results from StepResults associated with a given PipelineRun or TaskRun. With the new WhenExpressions in Steps feature, I'm guessing we'll need to do a change in Chains to process only the executed steps, and not all of them; processing not executed steps might result in an error (?). With that said I think we could open a new issue in Chains once this TEP is approved to track the needed effort there. @chitrangpatel @ericzzzzzzz please feel free to correct me if I'm wrong with my previous thoughts. Thanks!
|
@vdemeester PTAL when you have a chance 🙏 |
|
|
||
| ## Summary | ||
| This TEP proposes the addition of When Expressions to individual Steps within a Task. This will allow for fine-grained control over the execution of steps based on conditions like the status of previous step results. This enhancement will provide greater flexibility and control in defining task logic, enabling more complex and dynamic workflows. | ||
| ## Motivation |
There was a problem hiding this comment.
Anything described here can be achieved by "relatively" smart scripts in Steps, am I right ?
The "main" difference is in one case it's expressed with the tekton API, and on the other case, it's in "a script" or "in code".
There was a problem hiding this comment.
Only for inlined steps. This allows us to control the execution of stepActions where we don't have the ability to edit the scripts.
I think that's why it wasn't needed when we only had inlined steps. It is needed now that we have StepActions.
There was a problem hiding this comment.
Yes, I can hear that 😛 But one could also "condition" this in the StepAction with a parameter (probably a bit convoluted)
I think the core difference between the fact that Pipeline can fan-out (Matrix, DAG) vs Task is sequential will always remain. So it might appear that lines are being blurred but what you can do with Pipelines vs Tasks will always be different. If Tasks was a DAG of Steps then I agree that the lines would be truly blurred. I think the outcome will be the same as if the Step producing a TaskResult errored out. The Task author is controlling the flow of the StepAction/Step that is producing the result so they can choose. In this case, I think that the Task will error with the message that it could not produce a result (whatever the current behavior is if the Task does not generate a result)? |
Can we discuss this in the TEP ? |
I added a section to capture this. |
There was a problem hiding this comment.
Sorry, one more thing, can we dig a bit more into examples of use case it would fullfill ?
For example
- having "optional" set of caching steps (using StepAction) if a parameter is the
Task - having a "report" and fail step if the previous step fails
- … other use case we envision with this feature.
Hi, I added some examples. |
Description
This pull request proposes the ability to define When Expressions directly within Steps. This allows for fine-grained control over step execution based on conditions like the status of previous steps, enabling more dynamic and adaptable workflows.
Overview