-
New Feature
-
Resolution: Unresolved
-
Minor
The
waitUntil{}
block increases its wait time every time the condition fails. However, the user may have knowledge about the approximate time for the condition to pass. Jobs could proceed much faster if the user could limit the maximum interval before checking the condition again. Something like:
waitUntil{<cond>, <maxTime(min)>}
- is duplicated by
-
JENKINS-34554 workflow-basic-steps-plugin "waitUtil" should have a MAX_RECURRENCE_PERIOD
-
- Resolved
-
-
-
- Resolved
-
- links to
[JENKINS-29037] Add Max interval to waitUntil
Xavier Van Dessel
added a comment - If the average delay amounts to hours or days, as can be the case for resources, the delay becomes huge (hours), which cannot be justified by overhead cost. Hence, a maximum value makes a lot of sense in these cases.
Xavier Van Dessel
added a comment - If the average delay amounts to hours or days, as can be the case for resources, the delay becomes huge (hours), which cannot be justified by overhead cost. Hence, a maximum value makes a lot of sense in these cases. 
Simon So
added a comment - +1
The wait condition sometimes could take a day to two to turn true, so having an unbounded backoff makes it so that we pretty much can't use waitUtil.
As a side note, is there another way to pause and continue a pipeline triggered by an external event (like a git merge) without waitUtil?
Simon So
added a comment - +1
The wait condition sometimes could take a day to two to turn true, so having an unbounded backoff makes it so that we pretty much can't use waitUtil.
As a side note, is there another way to pause and continue a pipeline triggered by an external event (like a git merge) without waitUtil? There's a pull request against this issue https://issues.jenkins-ci.org/browse/JENKINS-34554 . It simply adds a limit.
Well, waitUntil as it stands will at worst waste an amount of time expressible as a fraction/multiple of the actual average delay before the condition stands, because it uses an exponential backoff. If it does scale up to a user-defined maximum, you would get a faster build at the expense of more overhead rechecking the condition.