Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Switch PipelineRun timeout -> TaskRun logic to instead signal the TaskRuns to stop #5134
Switch PipelineRun timeout -> TaskRun logic to instead signal the TaskRuns to stop #5134
Changes from all commits
c0c35fe
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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 wondering if there's a way to look at any of the finally TaskRuns and get their start time? Or would this introduce more race conditions?
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 thought about this, but at best it'd be messy, and I can't rule out the possibility of race conditions, inconsistent behavior, etc, so I opted for this. It's not bad information to have in general, I think - the dashboard or CLI or some other downstream consumer of
PipelineRun
s can just look at this field (plusStartTime
andCompletionTime
) to see how long just tasks took and how long finally tasks took, etc.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.
what is the existing behavior in terms what happens to the unscheduled tasks (dag and finally)? How is this different from what we have today?
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.
Right now, we create the tasks with a 1s timeout, so that they get created but immediately timeout. Skipping them instead is much more logical, imo.
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.
Wouldn't that be considered a behavior change? The users will start getting such tasks as part of the list of skipped tasks instead of
taskRun
s with cancelled status? 🤔skip
was introduced for conditional tasks and since then we have extended its usage in many different scenarios which is fine for now.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 is a slight behavior change, but not a functional one, since the end result is the same, just without the wasted steps of creating and immediately timing out the relevant task(s). I don’t think it’s an issue.
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.
Agreeing with @abayer
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.
How is this possible with the constraint we have documented?
Does this reason only apply to
finally
tasks? or can also be applied todag tasks
?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.
There are a few ways - dag tasks finishing quickly enough that the remaining time until the pipeline timeout is greater than the finally timeout, no pipeline timeout at all, etc. We’re using a different skipping reason for finally vs dag tasks to make the specific timeout setting that caused the timeout clear.
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 for fixing this 🙏
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.