-
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-0121: Retries - Reconciler Implementation #5844
Conversation
The following is the coverage report on the affected files.
|
1da1ab8
to
f5f814f
Compare
The following is the coverage report on the affected files.
|
/test pull-tekton-pipeline-integration-tests |
/assign @jerop cc @tektoncd/core-maintainers |
f5f814f
to
f0a7451
Compare
/unhold |
f0a7451
to
ac6d523
Compare
The following is the coverage report on the affected files.
|
ac6d523
to
c73c568
Compare
The following is the coverage report on the affected files.
|
c73c568
to
13aab95
Compare
The following is the coverage report on the affected files.
|
/hold until #5853 is fixed |
d1f83c6
to
2087371
Compare
The following is the coverage report on the affected files.
|
2087371
to
92569ed
Compare
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.
Thank you @XinruZhang for the great work on this and sorry about the late review 🙏
I have a few comments, but mostly minor or not blocking, or related to test coverage.
For events, I think it would be good align the events to the conditions, to be consistent to how things are today. It should be a minor change to implement, let me know what you think.
pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go
Outdated
Show resolved
Hide resolved
pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go
Outdated
Show resolved
Hide resolved
92569ed
to
27b2630
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
27b2630
to
944382f
Compare
The following is the coverage report on the affected files.
|
944382f
to
36cf2d8
Compare
The following is the coverage report on the affected files.
|
@chitrangpatel It looks like finally the go coverage work you made has been deployed, and I see that the coverage report is reported twice. However it looks like the links are broken for one of the two implementations. Would you mind having a look? |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
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.
/lgtm
Prior to this commit, `retries` logic for TaskRun is handled by Tekton `PipelineRun` reconciler. This commit delegates the retries implementation for `TaskRun` to the `TaskRun` reconciler. The major change is we stopped relying on `len(retriesStatus)` to decide if a target `TaskRun` failed or not. Instead, we use status `ConditionSuceeded` to gate the completion of a `TaskRun`. Even a `TaskRun` failed on one execution, as long as it has remaining retries, the TaskRun won't be stored in etcd with its status set as `Failed`. Instead, the status will be: ```yaml Type: Succeeded Status: Unknown Reason: ToBeRetried ```
36cf2d8
to
9be9e9a
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/lgtm |
Changes
This is the second peice of TEP-0121 implementation, targeting at merging it as part in release
v0.43.0
.Prior to this PR,
retries
logic for TaskRun is handled by TektonPipelineRun
reconciler. This PR delegates the retries implementation forTaskRun
to theTaskRun
reconciler.The major change is we stopped relying on
len(retriesStatus)
to decide if a targetTaskRun
failed or not. Instead, we use statusConditionSuceeded
to gate the completion of aTaskRun
. Even aTaskRun
failed on one execution, as long as it has remaining retries, the TaskRun won't be stored in etcd with its status set asFailed
. Instead, the status will be:It is worth noticing that, we still need to use
len(retriesStatus)
for Custom Tasks because currently we still support the alpha version, once we fully migrate custom task to the beta, we can safely remove that reliance.Note that the integration test retry_test.go still works.
This is a demo video in an API WG meeting [18:05-21:00]
/close #5756
/kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes