-
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
Add a Timeouts optional field to pipelinerun #3843
Conversation
Hi @souleb. 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.
|
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.
Thanks for this @souleb ! Looking good so far - I did a partial review and will grab some more time to look again tomorrow.
@@ -219,6 +219,11 @@ func (t *ResolvedPipelineRunTask) parentTasksSkip(facts *PipelineRunFacts) bool | |||
return false | |||
} | |||
|
|||
// IsFinalTask returns true if a task is a finally task | |||
func (t *ResolvedPipelineRunTask) IsFinalTask(facts *PipelineRunFacts) bool { |
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.
We could make facts.isFinalTask
public instead of wrapping it in a new function on the RPRT type. wdyt?
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'm assuming this isn't prevented for some other reason reason I'm missing?)
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.
It just seemed to me more natural to put it that way because I was expecting to find the function closed to IsFinallySkipped
. I like the idea of collocating those receiver function as they seem related. But i'm not against changing the scope of facts.isFinalTask
.
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.
Nope, there is no specific reason preventing it from going public i.e facts.isFinalTask
can be made public.
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 like the idea of collocating those receiver function as they seem related.
I see this a bit differently - IsFinallySkipped
is answering a question about the whole pipeline graph which requires the graph be fully "resolved", so makes sense on the ResolvedPipelineRunTasks
type. IsFinalTask
answers a question about a "fact" of an individual task of the pipeline, so makes sense to me to live on the PipelineRunFacts
type. (Edit to add: now that I read this again I'm actually not sure there's much distinction here after all :D)
Given that these two types (RPRT and PipelineRunFacts) are used so closely together in our code I don't feel super strongly either way. I just got a bit confused when I first read it because the two funcs are named so similarly and use the same objects 😅
b7f3bf9
to
c4a61fe
Compare
The following is the coverage report on the affected files.
|
I'm going to add a hold on this just so to ensure we get the TEP merged before this goes in. /hold Edit to add: also to wait until the feature gate work is in place. |
@souleb it would also be great to add an example YAML as part of this PR which shows the new field's usage too. |
One more thing that would be useful (sorry for the message spam!) would be to include some integration tests as well. These are quite a bit of work but it's good to have a fully-constructed pipeline run that tests timeout behaviour as part of our e2e test suite. See |
c4a61fe
to
9d5768a
Compare
The following is the coverage report on the affected files.
|
Sure, will do that. Just I wanted to wait for the TEP to be approved beforehand. |
9d5768a
to
f903552
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
a334074
to
11be900
Compare
5e894ee
to
4fc27b2
Compare
The following is the coverage report on the affected files.
|
@pritidesai will you have some time to review this PR? |
Thank you @souleb for all the changes and your patience 🙇♀️ Yes I will spend some time today to review this PR and continue early next week after long weekend. Thanks a bunch again for all your efforts 🙏 |
/retest |
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbwsg, 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 |
/test pull-tekton-pipeline-integration-tests |
@souleb please rebase this PR, its ready to merge. Thanks again for all the hard work. 🙏 |
TaskTimeout is used to timeout all dag tasks, finally tasks excluded Validates a TasksTimeout if: - TasksTimeout > 0 - Timeout is specified and TasksTimeout <= Timeout - Timeout not specified and TasksTimeout <= default Timeout Add a builder function for taskTimeout Defines 2 functions to get taskrun timeout One for dag tasks and one specifically for finally tasks
i.e. timeouts: pipeline: "0h0m60s" tasks: "0h0m30s" finally: "0h0m20s" All three subfields are optional
4fc27b2
to
a965afd
Compare
The following is the coverage report on the affected files.
|
/retest |
@vdemeester can reset the lgtm? The bot unset it following my rebase. |
/lgtm |
/retest |
/retest 🤔 |
tektoncd/pipeline#3843 was merged back in June. Signed-off-by: Andrew Bayer <[email protected]>
tektoncd/pipeline#3843 was merged back in June. Signed-off-by: Andrew Bayer <[email protected]>
tektoncd/pipeline#3843 was merged back in June. Signed-off-by: Andrew Bayer <[email protected]>
This PR is an implementation of TEP
#326
.Fixes issue
#2989
.Changes
Timeouts is a dict of timeout fields:
All three subfields are optional
Validates timeouts if:
- timeouts.pipeline >= timeouts.tasks + timeouts.finally
- all fields much be strictly positive
It is still possible to use
timeout
, but it is invalid to have bothtimeout
andtimeouts
. Thetimeout
behavior is unchanged.Have been tested with:
/kind feature
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes