Display Failed Task Information in Finally Task

[BlueCog]

Currently, when a pipeline fails, the Finally task is executed. I can trigger a failed or succesfull Finally with (as an example):

      when:
        - input: $(tasks.status)
          operator: in
          values: ["Failed"]

However, $(tasks.status) does not provide information about which task failed. I would like to see a parameter that is passed to the Finally task, indicating which task failed This information could be used in a script to post to GIT (comit/PR) for example, indicating which task failed and why and maybe provide some context.

I've tried tasks[*] for example. But that doesnt work (see https://tekton.dev/docs/pipelines/variables/)

[enarha]

/assign

[enarha]

@BlueCog while I'm looking into this issue, a quick way to get that information is by using the individual task statuses exposed as tasks.<task-name>.status. You can add an array type parameters for each task to your finally task in the form of ["<task-name>", "$(tasks.<task-name>.status)"]. These values can be combined into a single array and passed down to the script executed by the step, where you can find the the failed task. See an example here https://gist.github.com/enarha/2b40161c92d2ee921f9d56d1b3eb0409 .

[tekton-robot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[enarha]

/remove-lifecycle stale

[tekton-robot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten with a justification. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen with a justification. Mark the issue as fresh with /remove-lifecycle rotten with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[BlueCog]

Hi @enarha (do I spot Superfly as your avatar? :D),

Thanks for getting back at me.

I'm doing some editing on Tekton pipelines and just remembered this issue. I did some digging and it seems my initial question is still not possible, or at least not easily via a variable. Am I right?

I looked into your solution posted here but I was not able to get it to work. I'm getting a lot of errors from the API (probably a lot has changed in the meantime).

But this still feels a bit "hacky"? Wouldnt it be awesome if we could query the Tekton variable tasks so we would retrieve all tasks.<pipelineTaskNames> and the corresponding status?

For now, I got it to work like this (taking your solution in account). What could be used in further if statements.

Pipeline params:

      - name: task-result-init
        value: "task-result-init|$(tasks.init.status)"
      - name: task-result-build
        value: "task-result-build|$(tasks.build.status)"
      - name: task-result-check
        value: "task-result-check|$(tasks.check.status)"
      - name: task-result-analyse
        value: "task-result-analyse|$(tasks.analyse.status)"
      - name: task-result-release
        value: "task-result-release|$(tasks.release.status)"
        

Finally:

params:
    - name: task-result-init
      type: string
      default: "no value"
    - name: task-result-build
      type: string
      default: "no value"
    - name: task-result-check
      type: string
      default: "no value"
    - name: task-result-analyse
      type: string
      default: "no value"
    - name: task-result-release
      type: string
      default: "no value"
      
  steps:
    - name: set-status
      image: $(params.task-image)
      workingDir: $(workspaces.repo.path)
      script: |
        #!/bin/bash

        IFS='|' read -r task_name_init task_status_init <<< "$(params.task-result-init)"
        IFS='|' read -r task_name_build task_status_build <<< "$(params.task-result-build)"
        IFS='|' read -r task_name_check task_status_check <<< "$(params.task-result-check)"
        IFS='|' read -r task_name_analyse task_status_analyse <<< "$(params.task-result-analyse)"
        IFS='|' read -r task_name_release task_status_release <<< "$(params.task-result-release)"

        print_task_results() {
          local task_name="$1"
          local task_status="$2"
          echo "$task_name results: $task_status"
        }

        print_task_results "$task_name_init" "$task_status_init"
        print_task_results "$task_name_build" "$task_status_build"
        print_task_results "$task_name_check" "$task_status_check"
        print_task_results "$task_name_analyse" "$task_status_analyse"
        print_task_results "$task_name_release" "$task_status_release"

[BlueCog]

Hi @enarha

Is there any update on this?

Is there a possibility that this funcionality will be implemented in te future? That the name of failed task(s) is passed to the finally of a pipeline?

The workaround needs a lot of maintance and code... it would be easier if it could be used like operator in a when condition...

Or that (for example) tasks.status An aggregate status of all the pipelineTasks under the tasks section (excluding the finally section). This variable is only available in the finally tasks not only has one of the values (Succeeded, Failed, Completed, or None) but also (?) a dictionary of all invidual tasks with their status?