You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have many openshift/release jobs re-using common steps, like the "gather" steps.
The current configuration allows step timeouts as a statically-configured code change (for example), which means we must set to accommodate the slowest possible scenario.
However, smaller jobs may want to set a lower timeout so they can budget more time for other steps. We have seen that if a cluster-under-test is already broken, then the m-g step will not allow any following steps to complete before the job is terminated by the job-level timeout.
The enhancement:
Allow some means for a LiteralTestStep.Timeout to be overridden by an "end-user" test config (example).
Alternatives
It is possible there may be some way for us to achieve this configuration we may have missed. Please share with us if that's possible.
One way that comes to mind is cloning the step-registry ref so we can set different timeouts, but that seems like a fragile kind of forking approach that will create more maintenance burden on the test developer.
The text was updated successfully, but these errors were encountered:
Background
We have many openshift/release jobs re-using common steps, like the "gather" steps.
The current configuration allows step timeouts as a statically-configured code change (for example), which means we must set to accommodate the slowest possible scenario.
However, smaller jobs may want to set a lower timeout so they can budget more time for other steps. We have seen that if a cluster-under-test is already broken, then the m-g step will not allow any following steps to complete before the job is terminated by the job-level timeout.
The enhancement:
Allow some means for a LiteralTestStep.Timeout to be overridden by an "end-user" test config (example).
Alternatives
It is possible there may be some way for us to achieve this configuration we may have missed. Please share with us if that's possible.
One way that comes to mind is cloning the step-registry ref so we can set different timeouts, but that seems like a fragile kind of forking approach that will create more maintenance burden on the test developer.
The text was updated successfully, but these errors were encountered: