pipeline: Publish results when task and pipeline runs fail

I have a pretty basic use case for this @pritidesai and It seems like a pretty big oversight from where I am sitting!

1. I have a number of concurrent tasks that check quality and security and all report out their results.
2. If any of these checks fail, the overall build fails
3. I have a “finally” task that posts a summary of all testing back to the original merge request.

Right now I have to jump through hoops and upload/download my results with an external repo because I can’t rely on results on a failed job.

I want my “bot” to post a summary back especially if something failed, so that the end user knows why they failed.

Hey @lcarva We do not have a test/example to support the use of task results from a failed task in pipeline results. At least I can not recollect seeing it and remember that as something pending.

/remove-lifecycle stale

It would make sense to at least allow publishing pipeline results that are not depending on results of a failing task, the minimal reproducer is below. In my real-world use-case, I have a pipeline with task A publishing a result, task B using task A’s result, pipeline publishes a result based on task A result. When task A succeeds and task B fails, pipeline doesn’t publish result.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: hello-pipeline
spec:
  tasks:
  - name: hello
    taskSpec:
      results:
      - name: greeting
      steps:
      - name: greet
        image: registry.access.redhat.com/ubi8/ubi-minimal
        script: |
          #!/usr/bin/env bash
          set -e
          echo -n "Hello World!" | tee $(results.greeting.path)
          exit 1
  results:
  - name: myresult
    value: absolutely unrelated to hello task

Gotcha, Producing task result with onError might actually do the trick

I was re-reading the whole thread, and I think there are three different things describe in the thread:

1. taskruns emitting results in case of failure. We do not today because we don’t know if the results are valid. We could change this to emitting them (relatively small code change), we would be telling our users - this is what we go from the task, but since the task fail, it may be or may be not valid.
2. pipelinerun emitting results in case of failure. Pipelineruns are different because they basically only relay results. They may do some string concatenation but that’s about it. We could at least change the current behaviour to emit results that depend on tasks that did not fail. If we implemented (1), then we could emit all results regardless.
3. error specific result. One option here would be to pass the stderr of the failed step in a result, but that might be large and/or not helpful. We could allow task authors to specify the error, but that would be a lot more complex to implement since we would need to provide authors with a facility to create those results in case of failure, kind of a “finally step” or so. And it would require adding this facility to all existing catalog tasks.

Implementing (2) alone would solve @ppitonak issue and would be easy to implement. We could include a fixed string (i.e. NOT_AVAILABLE) in results that are not available, but if we did that we would need then to user no breaking changes on it.

I didn’t think in terms of error results before, I kind of expected results to be there in case of failure too, and I’m not sure why they are not. In case of a task failure we should provide as much context as available - why skip results then?

Note also that if you have a Task that depends on the result of another Task, and the Task producing the result fails, the Task consuming the result will not run.

e.g.:

TaskA
TaskB uses TaskA.results.foo

If TaskA fails or is skipped, TaskB will not run (which is where the optional results come in)

But @afrittoli maybe you’re not talking about making the result available to consuming Tasks, you’re talking specifically about putting it into the status of the TaskRun?

Yes, indeed.

The status will stay in etcd, might be gobbled up by chains, stored in results, sent over cloud events, trigger other parts of the workflow, so there is value in having that result even if it won’t be read by other tasks.

It may also be used by tasks in finally, once the corresponding TEP is implemented.

I didn’t think in terms of error results before, I kind of expected results to be there in case of failure too, and I’m not sure why they are not. In case of a task failure we should provide as much context as available - why skip results then? I was tempted to file this as bug, but I created it as a feature because the code explicitly skips results in case of failure.

Optional results are certainly an interesting topic, this TEP is related: https://github.com/tektoncd/community/pull/240. Default values for results may address some case but not when the result value needs to be produced by a step.