From 67feaa3c3bbf3cc0ac0f1486b9c37a60c55758cf Mon Sep 17 00:00:00 2001 From: Prashant Sharma Date: Thu, 5 Aug 2021 18:42:09 +0530 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Jason Hall --- docs/runs.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/runs.md b/docs/runs.md index 127424cc02e..23c497571ea 100644 --- a/docs/runs.md +++ b/docs/runs.md @@ -180,18 +180,18 @@ Supporting timeouts is optional but recommended. #### Developer guide for custom controllers supporting `Timeout` -1. A tektoncd owned controller will never directly update the status of the +1. Tekton controllers will never directly update the status of the `Run`, it is the responsibility of the custom task controller to support - timeout. + timeout. If timeouts are not supported, it's the responsibility of the custom + task controller to reject `Run`s that specify a timeout value. 2. On a `pipelineRun` or `pipelineTask` timeout, the status of the - `Run.Spec.Status` is updated to `RunCancelled`. It is upto the custom task - controller, to respond to it. An existing controller, which does not yet + `Run.Spec.Status` is updated to `RunCancelled`. It is up to the custom task + controller to respond to it. An existing controller, which does not yet support timeout, will be able to cleanup, if it supports a cancel. 3. 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 + any corresponding actions (i.e. a clean up e.g., cancel a cloud build, stop the waiting timer, tear down the approval listener). - ### Specifying `Parameters` If a custom task supports [`parameters`](tasks.md#parameters), you can use the