-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design and implement task results in final tasks #2557
Comments
/kind feature |
Boskos is a tool that allows one to create a pool of cloud projects (definitely GCP, I think it supports other providers as well), and manages acquiring, releasing, and cleaning them between leases. We use it for Tekton test infrastructure for our end to end tests and we'd like to use it for our catalog Tasks as well. This commit adds boskos acquire and release Tasks. The acquire Task also creates a pod in the running cluster to perform heartbeating so that boskos knows that the resource is still in use. The intention of the release Task is that it would be run in a Pipeline's `finally` clause, however today that would be difficult because finally Tasks can't yet use the results of other Tasks, but this functionality is on the way: tektoncd/pipeline#2557 This is part of the work in tektoncd#373 to create a Pipeline for the catalog.
Boskos is a tool that allows one to create a pool of cloud projects (definitely GCP, I think it supports other providers as well), and manages acquiring, releasing, and cleaning them between leases. We use it for Tekton test infrastructure for our end to end tests and we'd like to use it for our catalog Tasks as well. This commit adds boskos acquire and release Tasks. The acquire Task also creates a pod in the running cluster to perform heartbeating so that boskos knows that the resource is still in use. The intention of the release Task is that it would be run in a Pipeline's `finally` clause, however today that would be difficult because finally Tasks can't yet use the results of other Tasks, but this functionality is on the way: tektoncd/pipeline#2557 This is part of the work in tektoncd#373 to create a Pipeline for the catalog.
Boskos is a tool that allows one to create a pool of cloud projects (definitely GCP, I think it supports other providers as well), and manages acquiring, releasing, and cleaning them between leases. We use it for Tekton test infrastructure for our end to end tests and we'd like to use it for our catalog Tasks as well. This commit adds boskos acquire and release Tasks. The acquire Task also creates a pod in the running cluster to perform heartbeating so that boskos knows that the resource is still in use. The intention of the release Task is that it would be run in a Pipeline's `finally` clause, however today that would be difficult because finally Tasks can't yet use the results of other Tasks, but this functionality is on the way: tektoncd/pipeline#2557 This is part of the work in tektoncd#373 to create a Pipeline for the catalog.
Boskos is a tool that allows one to create a pool of cloud projects (definitely GCP, I think it supports other providers as well), and manages acquiring, releasing, and cleaning them between leases. We use it for Tekton test infrastructure for our end to end tests and we'd like to use it for our catalog Tasks as well. This commit adds boskos acquire and release Tasks. The acquire Task also creates a pod in the running cluster to perform heartbeating so that boskos knows that the resource is still in use. The intention of the release Task is that it would be run in a Pipeline's `finally` clause, however today that would be difficult because finally Tasks can't yet use the results of other Tasks, but this functionality is on the way: tektoncd/pipeline#2557 This is part of the work in tektoncd#373 to create a Pipeline for the catalog.
Boskos is a tool that allows one to create a pool of cloud projects (definitely GCP, I think it supports other providers as well), and manages acquiring, releasing, and cleaning them between leases. We use it for Tekton test infrastructure for our end to end tests and we'd like to use it for our catalog Tasks as well. This commit adds boskos acquire and release Tasks. The acquire Task also creates a pod in the running cluster to perform heartbeating so that boskos knows that the resource is still in use. The intention of the release Task is that it would be run in a Pipeline's `finally` clause, however today that would be difficult because finally Tasks can't yet use the results of other Tasks, but this functionality is on the way: tektoncd/pipeline#2557 This is part of the work in tektoncd#373 to create a Pipeline for the catalog.
/assign |
Boskos is a tool that allows one to create a pool of cloud projects (definitely GCP, I think it supports other providers as well), and manages acquiring, releasing, and cleaning them between leases. We use it for Tekton test infrastructure for our end to end tests and we'd like to use it for our catalog Tasks as well. This commit adds boskos acquire and release Tasks. The acquire Task also creates a pod in the running cluster to perform heartbeating so that boskos knows that the resource is still in use. The intention of the release Task is that it would be run in a Pipeline's `finally` clause, however today that would be difficult because finally Tasks can't yet use the results of other Tasks, but this functionality is on the way: tektoncd/pipeline#2557 This is part of the work in tektoncd#373 to create a Pipeline for the catalog.
Boskos is a tool that allows one to create a pool of cloud projects (definitely GCP, I think it supports other providers as well), and manages acquiring, releasing, and cleaning them between leases. We use it for Tekton test infrastructure for our end to end tests and we'd like to use it for our catalog Tasks as well. This commit adds boskos acquire and release Tasks. The acquire Task also creates a pod in the running cluster to perform heartbeating so that boskos knows that the resource is still in use. The intention of the release Task is that it would be run in a Pipeline's `finally` clause, however today that would be difficult because finally Tasks can't yet use the results of other Tasks, but this functionality is on the way: tektoncd/pipeline#2557 This is part of the work in tektoncd#373 to create a Pipeline for the catalog.
Boskos is a tool that allows one to create a pool of cloud projects (definitely GCP, I think it supports other providers as well), and manages acquiring, releasing, and cleaning them between leases. We use it for Tekton test infrastructure for our end to end tests and we'd like to use it for our catalog Tasks as well. This commit adds boskos acquire and release Tasks. The acquire Task also creates a pod in the running cluster to perform heartbeating so that boskos knows that the resource is still in use. The intention of the release Task is that it would be run in a Pipeline's `finally` clause, however today that would be difficult because finally Tasks can't yet use the results of other Tasks, but this functionality is on the way: tektoncd/pipeline#2557 This is part of the work in tektoncd#373 to create a Pipeline for the catalog.
Boskos is a tool that allows one to create a pool of cloud projects (definitely GCP, I think it supports other providers as well), and manages acquiring, releasing, and cleaning them between leases. We use it for Tekton test infrastructure for our end to end tests and we'd like to use it for our catalog Tasks as well. This commit adds boskos acquire and release Tasks. The acquire Task also creates a pod in the running cluster to perform heartbeating so that boskos knows that the resource is still in use. The intention of the release Task is that it would be run in a Pipeline's `finally` clause, however today that would be difficult because finally Tasks can't yet use the results of other Tasks, but this functionality is on the way: tektoncd/pipeline#2557 This is part of the work in #373 to create a Pipeline for the catalog.
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
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. |
/remove-lifecycle rotten |
@vdemeester: Reopened this issue. In response to this:
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. |
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 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? |
@spikeburton please look out for PR this week 🙏 |
@pritidesai great, thanks for the quick response 🙂 |
@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 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. |
@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 |
@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 |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
/remove-lifecycle stale Users are waiting for this feature. Implemented with #3242 which is still open. |
@pritidesai Hello.. I've come back to the task where I need to solve this problem I see the PR is merged.. looking forward to trying this! |
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:
WIP - implementing finally at the pipeline level 🤞🏼💥😱 #2437 (comment)
"Finally" tasks for Pipeline #2446 (Implement finally at the pipeline level)
Design: Failure Strategy for TaskRuns in a PipelineRun #1684 (part of designing failure strategy for taskrun in a pipeline)
The text was updated successfully, but these errors were encountered: