-
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
Implement timeout for custom tasks. #3976
Conversation
Hi @ScrapCodes. Thanks for your PR. I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/ok-to-test |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
4c54723
to
78a913b
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
78a913b
to
c467708
Compare
The following is the coverage report on the affected files.
|
c467708
to
9f1891f
Compare
## Changes Today, users can specify a timeout for a component Task of a Pipeline (see [PipelineTask.Timeout]) Remove the existing validation that forbids adding PipelineTask.Timeout to a custom task definition. The Run type will specify a Timeout field to hold this value when created as part of a PipelineRun (or when Runs are created directly). Custom Task authors can read and propagate this field if desired. Tekton-owned controller will not forcibly update the .status of a Run directly. This will be the responsibility of Custom Task controller. For a PipelineRun with either a pipeline level timeout configured and/or the custom task level timout configuration, timeout is updated to the run with same policy as it is for task runs. On timeout, the running run's status is updated with "RunCancelled". A Custom Task author can watch for this status update (i.e. Run.Spec.Status == RunCancelled) and or Run.HasTimedOut() and take any corresponding actions ( i.e. a clean up e.g., cancel a cloud build, stop the waiting timer, tear down the approval listener). Example: apiVersion: tekton.dev/v1alpha1 kind: Run metadata: generateName: simpleexample spec: timeout: 10s # set timeouts here. params: - name: searching value: the purpose of my existence ref: apiVersion: custom.tekton.dev/v1alpha1 kind: Example name: exampleName Unit and end to end test, ensures that on timeout either Pipeline level of task level, the custom task was patched /spec/status as RunCancelled.
1. Removed timeout from custom task limitations 2. Added an example
b09b5cb
to
e076b47
Compare
The following is the coverage report on the affected files.
|
/test tekton-pipeline-unit-tests |
@imjasonh @afrittoli do you have time to review this PR before the 0.27 release on Monday? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, just some docs comments otherwise this seems good to go.
@@ -51,7 +52,7 @@ import ( | |||
corev1 "k8s.io/api/core/v1" | |||
"k8s.io/apimachinery/pkg/api/errors" | |||
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" | |||
"k8s.io/apimachinery/pkg/labels" | |||
k8sApiLables "k8s.io/apimachinery/pkg/labels" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: labels
Maybe k8slabels
? Or, just keep the original import path, and don't rename it at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I renamed because, labels
is freely used as a variable name and it is also imported in the same scope. Do you think it is ok to keep it as labels
? (it failed a style check in my IDE though. )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel strongly either way, maybe k8slabels
67feaa3
to
fd3046f
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/test pull-tekton-pipeline-alpha-integration-tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have one nit in the docs but otherwise this looks ready to approve from my pov!
#### Developer guide for custom controllers supporting `Timeout` | ||
|
||
1. Tekton controllers will never directly update the status of the | ||
`Run`, it is the responsibility of the custom task controller to support |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am I right that what we mean here is that the custom task developer is expected to update the status/condition of the Run
? It might be worth describing a simple common status/condition/reason that is used for timeouts. I'm thinking something like:
- Once resources or timers are cleaned up it is good practice to set a
condition on theRun
'sstatus
ofSucceeded/False
with aReason
ofRunTimedOut
.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vdemeester The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Co-authored-by: Jason Hall <jasonhall@redhat.com>
fd3046f
to
a60722c
Compare
The following is the coverage report on the affected files.
|
/test tekton-pipeline-unit-tests |
/test pull-tekton-pipeline-integration-tests |
1 similar comment
/test pull-tekton-pipeline-integration-tests |
/lgtm |
We already designed and implemented support for `Timeouts` and `TaskSpec` in `Custom Tasks`. `Timeouts`: - TEP: tektoncd/community#433 - PR: tektoncd#3976 `TaskSpec`: - TEP: https://github.com/tektoncd/community/blob/main/teps/0061-allow-custom-task-to-be-embedded-in-pipeline.md - PR: tektoncd#3901 This item cleans up the todo items in `RunSpec`.
We already designed and implemented support for `Timeouts` and `TaskSpec` in `Custom Tasks`. `Timeouts`: - TEP: tektoncd/community#433 - PR: #3976 `TaskSpec`: - TEP: https://github.com/tektoncd/community/blob/main/teps/0061-allow-custom-task-to-be-embedded-in-pipeline.md - PR: #3901 This item cleans up the todo items in `RunSpec`.
We already designed and implemented support for `Timeouts` and `TaskSpec` in `Custom Tasks`. `Timeouts`: - TEP: tektoncd/community#433 - PR: tektoncd#3976 `TaskSpec`: - TEP: https://github.com/tektoncd/community/blob/main/teps/0061-allow-custom-task-to-be-embedded-in-pipeline.md - PR: tektoncd#3901 This item cleans up the todo items in `RunSpec`.
Tekton shall give custom task controller an opportunity to respect timeout and do a proper cleanup. It depends on the individual custom task controller implementation - how exactly it responds.
closes #3962
Changes
Tekton controllers does not forcibly update the
.status
of a Run directly, that responsibility belongs to the Custom Task controller.Run can be created with a timeout now, and it is upto the custom task controller to support it or not.
Custom tasks inside a PipelineRun with pipeline wide timeout and/or pipeline task level timeout is updated to run with same policy as it is for task runs. On timeout, the run's status is updated with "RunCancelled".
Added relevant tests.
Corresponding TEP update at: tektoncd/community#433
/kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
Release Notes