TEP-0045: When Expressions in Finally Tasks

[jerop]

Users can guard execution of Tasks using WhenExpressions,
but that is not supported in Finally Tasks.

This TEP describes the need for supporting WhenExpressions in
Finally Tasks not only to provide efficient guarded execution
but also to improve the reusability of Tasks.

Given we've recently added support for Results and Status in
Finally Tasks, this is an opportune time to enable WhenExpressions
in Finally Tasks.

/kind tep
/cc @pritidesai @bobcatfish @sbwsg

[bobcatfish]

/assign @pritidesai
/assign @sbwsg

[ghost]

Adding this feature makes sense to me and composes well with the existing access Finally tasks get to results and status. 👍

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbwsg

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:

• teps/OWNERS [sbwsg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[pritidesai]

thanks @jerop

This looks good in proposed state. Please add more design details while making it implementable.

When expressions are so far evaluated after successful or skipped tasks. Will need to address failure scenario in the when expression evaluation i.e. a result reference in when expression could be missing and the finally task ends up in the list of skipped tasks v/s when expression with mismatching inputs and values evaluating to false. This will be no different than how we have implemented task results in finally.

This also makes me think guard and finally together sounds very odd. Should we change the title again to drop guarding? when expression is bringing reusability rather than guarding it compared to non-finally tasks.

[jerop]

thanks for the reviews @sbwsg & @pritidesai!! 🙏🏾

This looks good in proposed state. Please add more design details while making it implementable.

I've added more details about using Parameters, Results and Execution Status, and also addressed the validation and failure scenarios -- please let me know if there's something more you'd like to see

When expressions are so far evaluated after successful or skipped tasks. Will need to address failure scenario in the when expression evaluation i.e. a result reference in when expression could be missing and the finally task ends up in the list of skipped tasks v/s when expression with mismatching inputs and values evaluating to false. This will be no different than how we have implemented task results in finally.

Yes, in both scenarios, they'd be skipped and added to the Skipped Tasks in status -- another reason to look into adding Reason to Skipped Tasks and revisit the general Status design

community/teps/0045-reusability-and-guarding-of-tasks-finally.md

Lines 232 to 234 in bf680b7

	If the `WhenExpressions` in a `Finally Task` use `Results` from a skipped or failed non-finally `Tasks`, then the
	`Finally Task` would also be skipped and be included in the list of `Skipped Tasks` in the `Status`, [similarly to when
	`Results` in other parts of the `Finally Task`](https://github.com/tektoncd/pipeline/blob/master/docs/pipelines.md#consuming-task-execution-results-in-finally).

This also makes me think guard and finally together sounds very odd. Should we change the title again to drop guarding? when expression is bringing reusability rather than guarding it compared to non-finally tasks.

@pritidesai, what do you think of Reusability and Guarding of Tasks in Finally for the title?

I'd say the same argument about WhenExpressions improving reusability of Tasks in Finally also applies to the DAG (non-finally), plus I think excluding guarding in the title would imply this TEP is focused more broadly on the reusability of Finally Tasks beyond supporting WhenExpressions

[pritidesai]

thanks @jerop, we could add more relevant examples for using task results and params with when expressions but its not blocking this proposal.

Thanks for all the updates 🙏

/lgtm