Pipeline: Expose pipeline run metadata to Tasks and Conditions

[dibyom]

Condition containers need access to metadata about the pipeline run. The metadata will be in the form of a pr-metadata.json file that is present in the workspace directory.

Part of implementation of #27

ref: https://github.com/tektoncd/pipeline/issues/1137

[dibyom]

/assign

[dibyom]

Created a design proposal here: https://docs.google.com/document/d/1eJBb2VHuSTbrIWfPE3TGdRRfdbJsRCOBIqfTwx9M3H8/edit#heading=h.2f7asw3l4lo9

(to view this join the tekton-dev@ mailing list: https://github.com/tektoncd/community/blob/master/contact.md#mailing-list )

[vdemeester]

/kind feature
/area api

[bobcatfish]

@dibyom are you still working on this or can we throw it back in the backlog?

[dibyom]

@dibyom are you still working on this or can we throw it back in the backlog?

Thanks for the reminder. Moved to backlog -- here's why:

1. There is a workaround that @akihikokuroda mentioned in the design doc: https://github.com/tektoncd/pipeline/issues/1016#issuecomment-542388985

2. The injected pipelinerun status is likely to be stale if there are parallel taskruns -- to counter the user would have to resort to the workaound above

3. Probably not going to be useful until we have #1376 as well.

I think we should take another look at this post #1376

[pritidesai]

This feature is essential for finally, final tasks are executed after all Pipeline Tasks are finished executing with success or after a single Pipeline Task fails. The scope of this design goes beyond just conditional containers, and applies to all final task containers and possibly all pipeline task containers.

Design Doc

@dibyom I would like to collaborate on the design if I can, planning on working on it after core finally functionality is merged (PR #2650 and PR #2661). Looking at the design right now 👀

Assigning it to myself as well, please let me know if there is any issue 🙏

/assign

[dibyom]

Excellent!! 😃
I had a old proposal though I am not sure how much of that is still relevant especially with finally containers! Feel free to suggest something different it that makes more sense!

[bobcatfish]

I think @dibyom 's proposal to provide this info via json file is a great first step toward what we need for both conditions + finally. We can always follow that up with more power around variable interpolation if needed.

[pritidesai]

@popcor255 do you have any particular use case or story you would like to be supported with this feature request?

[popcor255]

@pritidesai Yes, as a user I would like to log my pipelines with something with logDNA/ELK. However, this work around looks like I should be able to get the name of the pipelinerun I am under. This should let me use a step with kubctl to get the params. :smile:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: fetch-my-pipelinerunner
spec:
  steps:
  - name: kubeconfig
    image: bitnami/kubectl
    script: |
      kubectl get pipelineruns $PIPELINERUN -o json
    env:
    - name: PIPELINERUN
      valueFrom:
        fieldRef:
          fieldPath: metadata.labels['tekton.dev/pipelineRun']

[sbwsg]

not sure if this has been discussed elsewhere but the pipeline run's name is also available as a context variable in Pipelines which you can then pass to Tasks as a param. see the using_context_variables example: https://github.com/tektoncd/pipeline/blob/master/examples/v1beta1/pipelineruns/using_context_variables.yaml#L30-L34

[pritidesai]

I am narrowing down the scope here:

Goal

Access to execution status of other taskRuns within the same Pipeline.

Proposal

Introduce execution status as a context variable (thanks @sbwsg for pointing out about context variables) in the form of $(context.pipelineRun.Tasks.<pipelineTaskName>)". This variable can have one of the following values:

1. Succeeded: taskRun for that pipelineTask completed successfully
2. Failed: taskRun for that pipelineTask completed with a failure
3. TaskRunCancelled: taskRun for that pipelineTask is cancelled by the user
4. Skipped: that pipelineTask is skipped
5. Unknown: no information available on that pipelineTask execution

Usage

kind: PipelineRun
apiVersion: tekton.dev/v1beta1
metadata:
  generateName: test-pipelinerun-
spec:
  serviceAccountName: 'default'
  pipelineSpec:
    tasks:
    - name: task1
      params:
      taskSpec:
        steps:
        - image: ubuntu
          name: hello
          script: |
            echo "Hello World!"
    - name: task2
      runAfter: [ "task1" ]
      taskSpec:
        steps:
          - image: ubuntu
            name: fail
            script: |
              exit 1
    finally:
    - name: task3
      params:
        - name: pipelineRun-pipelineTask-task2
          value: "$(context.pipelineRun.Tasks.task2)"
      taskSpec:
        params:
          - name: pipelineRun-pipelineTask-task2
        steps:
          - image: ubuntu
            name: print-failed-task-status
            script: |
              if [ $(params.pipelineRun-pipelineTask-task2) == "Failed" ]
              then
                echo "Task2 has failed, continue processing the failure"
              fi

Will add more details but before that, wanted to collect feedback if this proposal is heading in right direction and would solve the use cases we have today.

[jrcast]

@pritidesai what do you think about adding a status field for the pipelinerun itself? That way we can easily check for the pipelinerun state as part of a _generic_ finally task which we can reuse across pipelines regardless of which tasks we reference. Maybe you can follow the "True", "False", "Unknown" approach as seen here or spell out the Reason or both 🤷

Imagine, something like:

    finally:
    - name: notify-results
      params:
        - name: pipelineRunStatus
          value: "$(context.pipelineRun.status)"  
        - name: pipelineRunStatusReason
          value: "$(context.pipelineRun.reason)" 
      taskSpec:
        params:
          - name: pipelineRunStatus
        steps:
          - image: ubuntu
            name: notify-status
            script: |
              if [ $(params.pipelineRunStatus) == "True" ]
              then
                echo "PipelineRun was successful. Status was marked as  $(params.pipelineRunStatusReason)"
              else
                echo "PipelineRun Failed. Status was marked as  $(params.pipelineRunStatusReason)"
              fi

This task could be defined as a standalone Task instead of a taskSpec and used as a finally task in _any_ pipeline using taskRef. I think this would be really useful.

[pritidesai]

hey @jrcast I am not sure how pipelineRun status can be helpful here? finally is part of the same run and pipelineRun status is set to running until the pipeline finishes execution i.e. until finishes executing finally tasks.

Also, I have TEP created for this if you want to take a look 🙏

[verokarhu]

I am narrowing down the scope here:

Goal

Access to execution status of other taskRuns within the same Pipeline.

Proposal

Introduce execution status as a context variable (thanks @sbwsg for pointing out about context variables) in the form of $(context.pipelineRun.Tasks.<pipelineTaskName>)". This variable can have one of the following values:

1. Succeeded: taskRun for that pipelineTask completed successfully
2. Failed: taskRun for that pipelineTask completed with a failure
3. TaskRunCancelled: taskRun for that pipelineTask is cancelled by the user
4. Skipped: that pipelineTask is skipped
5. Unknown: no information available on that pipelineTask execution

Usage

kind: PipelineRun
apiVersion: tekton.dev/v1beta1
metadata:
  generateName: test-pipelinerun-
spec:
  serviceAccountName: 'default'
  pipelineSpec:
    tasks:
    - name: task1
      params:
      taskSpec:
        steps:
        - image: ubuntu
          name: hello
          script: |
            echo "Hello World!"
    - name: task2
      runAfter: [ "task1" ]
      taskSpec:
        steps:
          - image: ubuntu
            name: fail
            script: |
              exit 1
    finally:
    - name: task3
      params:
        - name: pipelineRun-pipelineTask-task2
          value: "$(context.pipelineRun.Tasks.task2)"
      taskSpec:
        params:
          - name: pipelineRun-pipelineTask-task2
        steps:
          - image: ubuntu
            name: print-failed-task-status
            script: |
              if [ $(params.pipelineRun-pipelineTask-task2) == "Failed" ]
              then
                echo "Task2 has failed, continue processing the failure"
              fi

Will add more details but before that, wanted to collect feedback if this proposal is heading in right direction and would solve the use cases we have today.

Most of my pipelines are at least 5 tasks, there are a few that are over 10. Configuring a finally task for e.g. reporting build status would be complicated as it would have to take the result of each single task as an input. It would also have to be customised for each pipeline and if someone adds a task they need to remember to update the finally task.

I think the idea @jrcast presented is in the right direction. We need a way to get the aggregated results of all the tasks without having to specify each single task. It would also make the finally task more reusable.

[pritidesai]

@verokarhu, the idea @jrcast presented about reading the pipelineRun status does not work since when the finally tasks are starting to execute, the pipelineRun status would be still running not succeeded or failed as pipelineRun status also includes status from finally tasks and not considered completed/done until finally tasks finish executing i.e. pipelineRun status does not represent aggregate status/results of all tasks under tasks section.

In addition to getting individual task execution status, we could add another context variable to get the aggregate results of all tasks using $(context.pipelineRun.Tasks.status) set to succeeded or failed , thoughts?

[pritidesai]

Also, the overall idea here is to include these context variables as by default available instead of explicitly mapping in future.

[jrcast]

In addition to getting individual task execution status, we could add another context variable to get the aggregate results of all tasks using $(context.pipelineRun.Tasks.status) set to succeeded or failed , thoughts?

I think the aggregate results of _all_ tasks would do the trick. If all tasks are, let's say, suceeded, then $(context.pipelineRun.Tasks.status) should be succeeded or True right?. If any one of the tasks is failed or equivalent, then the aggregate should be failed or False. I think something like this would still allow to reuse the finally task regardless of the pipeline in question without having to write and maintain such finally task each time the pipeline tasks change.

[pritidesai]

If all tasks are, let's say, suceeded, then $(context.pipelineRun.Tasks.status) should be succeeded or True right?. If any one of the tasks is failed or equivalent, then the aggregate should be failed or False.

Yes and as the variable says tasks, this does not include any of the finally tasks.

I will think of alternate name to avoid any confusion, otherwise, this sounds good.

[pritidesai]

@vdemeester this is the use case I was referring to about accessing aggregate execution status of all tasks in finally.

[riceluxs1t]

Hi. We also have a use case where a Tekton pipeline consists of task A -> task B -> finally task C. The finally task C wants to perform a different logic if either task A or task B fails. In our case, the pipeline topology is fixed and the finally task C can enumerate over the status of its previous two tasks. However, like others suggested, aggregate information would be useful and save the task C the enumeration job.

I mainly wonder if this feature is being currently worked on and if so, how I can track its progress

[jerop]

I mainly wonder if this feature is being currently worked on and if so, how I can track its progress

@riceluxs1t a proposal by @pritidesai was accepted and she implemented it already