-
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
Design and implement timeouts #222
Comments
In Jenkins Pipeline, users are able to specify whether a timeout is absolute or relative to the last log activity (activity parameter here). I think the relative option is mostly used for long builds where an absolute timeout would be too long to be useful, but the build is expected to produce log output very consistently. In that case, a timeout after 5 minutes of no log activity can be helpful to make sure builds are not stuck doing nothing for hours before they fail. I'm not necessarily convinced that relative timeouts are necessary, or if log output is the best way to determine activity, but it seems like something worth discussing. |
I'm personally not a huge fan of the relative timeouts in Jenkins - it seems like a useful thing, but I find that in practice, the use cases for "timeout after inactivity" that aren't adequately covered by "timeout after absolute amount of time" are pretty negligible, and probably not worth the extra effort to implement/support. But that's just my two cents. |
Now that I've spent a bit more time digging into the actual code - looks like this already exists for Task, via Build, so we'll just need to add the same thing to Pipeline, yes? |
/assign @abayer |
@vdemeester: GitHub didn't allow me to assign the following users: abayer. Note that only knative members and repo collaborators can be assigned. In response to this:
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. |
So from discussion in Slack, it feels like the first step is a more general "cancel this running PipelineRun" mechanism, which would be utilized both for timing out the PipelineRun and for manually canceling a running PipelineRun without deleting the PipelineRun/TaskRun/etc. This would probably entail a new So putting aside the implementation details there, I'm also trying to determine how this would work in PipelineRun's reconciler - if the |
Oh, and that all implicitly requires changes in Build's reconciler - which raises the question of whether to worry about doing that now or just waiting until Build has been folded into here. |
Yes, I'm pretty sure we already do sthg along those lines in
So, I think the
🤔
I think it "still" make sense to make the change in |
Ok, I've only barely looked at I think we would want to only update the status to |
I'd like to plug having two separate Reasons here:
Seems worthwhile to be able to tell which was the cause.
I don't think we should be expecting users to modify anything in the
Maybe something like:
Contrary to @vdemeester 's advice I'd implement it here first, maybe only here 😇 something like:
So the only feature to add to Builds potentially would be cancellation? @imjasonh correct me if I'm wrong but I don't think we want to end up in a world where folks have to add features to both Task + Build |
@bobcatfish yes that's the only thing I suggest to implement in build — sorry if it wasn't clear. And I'm definitely ok for it to be implemented here first 😛
Yes 👍 Should we split this into 2 issues (cancellation & timeout) ? |
/assign @abayer |
@vdemeester - yeah, it sounds reasonable to split into two issues. We can do the hackish approach for cancelling Builds when the PipelineRun times out for now (i.e., modifying the Build CRD instance on the fly to force it to timeout), and then add true cancellation support to Build as part of the Pipeline/PipelineRun cancellation work. Once real cancellation for Builds is in place, we can then switch the PipelineRun timeout behavior to use that instead of the hack. |
This still needs work - for example, it can't kill running Builds yet, but I'm waiting for cancellation (i.e., tektoncd#272) to be a thing before actually implementing that part. Fixes tektoncd#222
This still needs work - for example, it can't kill running Builds yet, but I'm waiting for cancellation (i.e., tektoncd#272) to be a thing before actually implementing that part. Fixes tektoncd#222
Rebased and squashed the initial work, more to come. Fixes tektoncd#222
Rebased and squashed the initial work, more to come. Fixes tektoncd#222
Rebased and squashed the initial work, more to come. Fixes tektoncd#222
Rebased and squashed the initial work, more to come. Fixes tektoncd#222
Rebased and squashed the initial work, more to come. Fixes tektoncd#222
Expected Behavior
A user should be able to specify timeouts at the:
If a user does not specify timeouts, then some default should be used and it should be clear what that is:
Actual Behavior
Currently this is possible via the build spec for Tasks only.
Additional Info
The text was updated successfully, but these errors were encountered: