Pipeline: Design and implement task results in final tasks

[pritidesai]

finally at the pipeline level is on its way:

design doc
PR - which will be split into multiple PRs

First iteration of final tasks are implemented without task results and from clause for Pipeline Resources. In next iteration, please finalize the design for adding support for task results.

Reference:

• https://github.com/tektoncd/pipeline/pull/2437#discussion_r420298647

• https://github.com/tektoncd/pipeline/issues/2446 (Implement finally at the pipeline level)

• https://github.com/tektoncd/pipeline/issues/1684 (part of designing failure strategy for taskrun in a pipeline)

[vdemeester]

/kind feature

[pritidesai]

/assign

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

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

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[vdemeester]

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

[tekton-robot]

@vdemeester: Reopened this issue.

In response to this:

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[spikeburton]

We have a use case for this functionality with the MacStadium Orka Tasks. We have a Task that will perform some initialization (token fetch and configuration generation) which should then be cleaned up by another Task in a pipeline with finally. The clean up Task needs to then revoke the token and purge the configuration. I was planning to pass the name of the configuration to the clean up Task through results.

I have a temporary workaround, but I think passing the results of the init Task as params would be ideal.

What is the timeline looking like for this functionality to be available?

[pritidesai]

@spikeburton please look out for PR this week 🙏

[spikeburton]

@pritidesai great, thanks for the quick response 🙂

[mbwhite]

@spikeburton would you mind sharing the workaround please? My use case I want to send a message to slack saying if the build worked or not... and was hoping to pass that in a result.

[spikeburton]

@mbwhite sure, for our use case I am using a config map as a workaround to make data available between tasks. However, this requires setting up a service account which is able to create / delete config maps using kubectl.

[pritidesai]

@spikeburton would you mind sharing the workaround please? My use case I want to send a message to slack saying if the build worked or not... and was hoping to pass that in a result.

@mbwhite can you please explain your use case in terms of what exactly being passed as a task result? is build failure causing task failure in your pipeline?

For communicating build success/failure, @mbwhite I have another feature being implemented accessing execution status of a task, would that be helpful?

• TEP
• PR

[mbwhite]

@pritidesai Hello.. here's the use case.

The pipeline is primarily aimed at testing: there are a few build tasks, then a number of test tasks. These run against cloud resources (provisioned at the start of pipeline).

The finally is there is clean up the cloud resources - and ideally I'd like to be able to report the success or failure of the various tasks. Failure being more important as that means we've got a problem.

Your 'accessing execution status' does sound like it could be useful here.

Thanks