TEP-0049: access aggregate status of the dag tasks from finally

[pritidesai]

TEP-0028 implemented params such as $(tasks.<pipelineTask>.status) to access the execution status of a dag task from the finally section. This works great for a pipeline where a finally task depends on the execution status of an individual dag task. We have discovered additional use cases where a finally task needs to be executed if ANY one of the dag tasks fail.

This TEP is proposing an additional variable $(tasks.status) to access aggregate status of the dag tasks.

Related issues and PR:

tektoncd/pipeline#3806
tektoncd/pipeline#1020 (comment)
tektoncd/pipeline#3738 (comment)

[pritidesai]

/kind tep

[jerop]

/assign

[jerop]

excited for this feature 🎉

thanks @pritidesai!

[dibyom]

/assign @skaegi

[eliihen]

Looks great, @pritidesai! You requested my feedback on if this matches my expectations in tektoncd/pipeline#3806 (comment), and it does indeed 👏🏻

It may be out of scope of this TEP, but the coming "pipeline-in-pipeline" proposal may affect this proposal and vice versa. If they work together it will be a pretty cool feature though. Just checking if you thought about any potential issues with the implementation there.

Finally, I just wanted to sanity check this proposal. Say we have a pipeline of tasks A -> B -> C. Would this proposal be necessary if we instead did the following:

finally:
  - when:
    - input: "$(tasks.C.status)"
      operator: notin
      values: ["Succeeded"]

Here we have a when condition that checks the status of the final task in the pipeline. If any of the tasks before task C fails, task C will not have the status of "Succeeded", so the finally will run. Thus the final task's status is sort of an aggregate of the pipeline's status. This was not immediately obvious to me earlier, but it seems to work. I'm not sure if this misses any usecases (what about forking pipelines for example), but it's fair to consider it. In any case this proposal provides a nice a nice shorthand and makes it easier to move tasks around.

[pritidesai]

Looks great, @pritidesai! You requested my feedback on if this matches my expectations in tektoncd/pipeline#3806 (comment), and it does indeed 👏🏻

Thanks @esphen ❤️

It may be out of scope of this TEP, but the coming "pipeline-in-pipeline" proposal may affect this proposal and vice versa. If they work together it will be a pretty cool feature though. Just checking if you thought about any potential issues with the implementation there.

pipeline-in-pipeline is a great feature and still being designed. It will be great to have exposure to the subpipelines status in finally.

Finally, I just wanted to sanity check this proposal. Say we have a pipeline of tasks A -> B -> C. Would this proposal be necessary if we instead did the following:

finally:
  - when:
    - input: "$(tasks.C.status)"
      operator: notin
      values: ["Succeeded"]

Here we have a when condition that checks the status of the final task in the pipeline. If any of the tasks before task C fails, task C will not have the status of "Succeeded", so the finally will run. Thus the final task's status is sort of an aggregate of the pipeline's status. This was not immediately obvious to me earlier, but it seems to work. I'm not sure if this misses any usecases (what about forking pipelines for example), but it's fair to consider it.

This workaround would not work for the following pipeline with multiple last tasks:

          A
      /        \
    B          C

B and C are executed at the same time. One of them can fail while the other could succeed/skipped. Can not rely on the last tasks for the aggregate status in this example.

In any case this proposal provides a nice a nice shorthand and makes it easier to move tasks around.

Thank you 👍

[vdemeester]

/lgtm

[pierretasci]

we can maybe leave this to the implementation, but we probably want to put this on the pipeline not on tasks like pipeline.status

[pierretasci]

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jerop, pierretasci

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 [jerop]

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