-
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
TEP-0069: Support retries for custom task in a pipeline. #4135
Conversation
1. Add field `Retries` to `RunSpec`, an integer count which acts as a FYI to custom task controller. 2. Add a new `RunRetry`, in addition to `RunCancelled` status to `RunSpecStatus` i.e. `v1alpha1.RunSpecStatusRetry` 3. Add a field `RetriesStatus` to `RunStatusFields`, to maintain the retry history for a `Run`, similar to `v1beta1.TaskRunStatusFields.RetriesStatus` 4. Add a config map entry (default-short-timeout-seconds) to `config-defaults` in order to make short timeout configurable. Proposed algorithm for performing a retry for custom task. - Step 1. A `pipelineTask` consisting of a custom task X, is configured with `retries` count. - Step 2. On failure of task X, `pipelinerun` controller sees a request for a retry. It then communicates the same to custom task `Run` by patching `/spec/status` with a `v1alpha1.RunSpecStatusRetry` i.e. `RunRetry`. Similar to request a custom task to cancel. - Step 3. In addition to patching the `pipelinerun` controller also enqueue a timer `time.After(default-short-timeout-seconds)` (default: 30 seconds). On completion of timeout (i.e. 30s), it checks if `/spec/status` is `RunRetry`, then it assumes that custom task does not support retry. - a) if custom task does not supports retry as above, It sets no. of `retry done` to the `retries` count configured - i.e. exhaust all retries. - b) if custom task does support retry, update retry history. - Step 4. The custom task that wants to support the retry, has to update - a) `status.conditions` to indicate it is `Running`. - b) clear `/spec/status` if it is `RunRetry`. _A task may retry and immediately fail, so controller cannot fully rely on `status.conditions`._ Docs changes 1. Removed the limitation that retries are not supported for custom task. 2. Add a short user guide for custom task developer.
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
The following is the coverage report on the affected files.
|
Currently, I am using |
@ScrapCodes: PR needs rebase. 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. |
Thanks @ScrapCodes - I look forward to the new PR then! |
Yeah @afrittoli, I have proposed a new approach see tektoncd/community#491 |
Changes
Retries
toRunSpec
, an integer count which acts as a FYI tocustom task controller.
RunRetry
, in addition toRunCancelled
status toRunSpecStatus
i.e.
v1alpha1.RunSpecStatusRetry
RetriesStatus
toRunStatusFields
, to maintain the retryhistory for a
Run
, similar tov1beta1.TaskRunStatusFields.RetriesStatus
config-defaults
inorder to make short timeout configurable.
Proposed algorithm for performing a retry for custom task.
Step 1. A
pipelineTask
consisting of a custom task X, is configured withretries
count.Step 2. On failure of task X,
pipelinerun
controller sees a request for aretry. It then communicates the same to custom task
Run
by patching/spec/status
with av1alpha1.RunSpecStatusRetry
i.e.RunRetry
. Similarto request a custom task to cancel.
Step 3. In addition to patching the
pipelinerun
controller also enqueue a timertime.After(default-short-timeout-seconds)
(default: 30 seconds).On completion of timeout (i.e. 30s), it checks if
/spec/status
isRunRetry
,then it assumes that custom task does not support retry.
retry done
to the
retries
count configured - i.e. exhaust all retries.Step 4. The custom task that wants to support the retry, has to update
status.conditions
to indicate it isRunning
./spec/status
if it isRunRetry
.A task may retry and immediately fail, so controller cannot fully rely on
status.conditions
.Docs changes
/kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
Release Notes