Skip to content

Latest commit

 

History

History
136 lines (102 loc) · 6.26 KB

0049-aggregate-status-of-dag-tasks.md

File metadata and controls

136 lines (102 loc) · 6.26 KB
status title creation-date last-updated authors
implemented
Aggregate Status of DAG Tasks
2021-03-04
2021-06-03
@pritidesai

TEP-0049: Aggregate Status of DAG Tasks

Summary

Note In this TEP, dag task refers to pipelineTask in the tasks section and finally task refers to pipelineTask in the finally section.

A finally task in a pipeline has access to the execution status of any dag task through a context variable $(tasks.<pipelineTask>.status). TEP-0028: Task Execution Status at Runtime implemented this context variable which is instantiated and available at the runtime. This context variable is set to Succeeded, Failed, or None depending on the execution status of that task and generally consumed in when expressions:

    finally:
      - name: notify-build-failure # notify build failure only when golang-build task fails
        when:
          - input: $(tasks.golang-build.status)
            operator: in
            values: ["Failed"]
        taskRef:
          name: send-to-slack-channel

This works great for a pipeline where a finally task depends on the execution status of an individual dag task. We often run into the use cases where a finally task needs to be executed if any one of the dag tasks fail. This use case can also be accomplished by explicitly spelling out each dag task in the comparison:

finally:
      - name: notify-any-failure # executed only when any dag task fail
        when:
          - input: "Failed"
            operator: in
            values: [$(tasks.unit-tests.status), $(tasks.golang-build.status), $(tasks.deploy.status)]

But, this solution does not scale well with a larger pipeline with 50 to 60 dag tasks. It explodes the when expressions with the entire list of dag tasks. Also, every time a pipeline is updated to add/delete a dag task, the pipeline author has to remember to update when expressions in the finally task as well.

These concerns can be addressed by introducing a context variable with an aggregate status of all the dag tasks, $(tasks.status).

Motivation

  • A pipeline author wants to perform some operation or execute a finally task as part of the same pipeline if one of the dag tasks fail.

Goals

  • The main goal of this proposal is to allow access to aggregate status of all dag tasks within the pipeline in finally at runtime. An additional goal of this proposal is to align the aggregate status to pipelineRun status.

Non-Goals

  • This proposal does not allow dag tasks to access aggregate status of the dag tasks.

  • This proposal is not to expose the entire status of a taskRun/pipelineRun as metadata at runtime.

Use Cases

  • As a pipeline author, I would like to design a finally task to send failure notification to slack if any dag task fail.

Proposal

Introduce a new variable $(tasks.status) which resolves to one of the execution states: Succeeded, Failed, and Completed.

This variable is instantiated and available at the runtime. In the following example, the pipeline has ten dag tasks and a finally task to send failure notifications. The finally task, notify-any-failure, checks the aggregate execution status of dag tasks using this variable and continues if it is set to Failed.

finally:
      - name: notify-any-failure # executed only when one of the dag tasks fail
        when:
          - input: $(tasks.status)
            operator: in
            values: ["Failed"]
State Description
Succeeded All dag tasks have succeeded.
Failed Any one of the dag task failed.
Completed All dag tasks completed successfully including one or more skipped tasks.
None No aggregate execution status available (i.e. none of the above) because some of the tasks are still pending or running or cancelled or timed out.

$(tasks.status) is not accessible in any dag task but only accessible in a finally task. The pipeline creation will fail with the validation error if $(tasks.status) is used in any dag task.

Test Plan

All necessary e2e, unit tests, and example will be added.

Alternatives

Introduce the same variable but with an alternate name $(pipeline.status) instead of $(tasks.status).

The only downside to naming it this way is, it might confuse the users since this variable represents the overall status of the tasks section and not the entire pipeline.

References