![]() |
|
|
|
|
Change By:
|
Daniel Beck
(19/Dec/13 9:40 PM)
|
|
Description:
|
Disregarding jobs where there are significant differences (e.g. parameters causing every other build to do twice the work) between builds, we
We
use the estimated build time mostly to determine '_by when
do
will
we have a result?_'. There is some (±5-10%, the longer the duration the less variation) variation between durations of successful builds, but it's still good enough for an estimate
based on how the UI works
(disregarding jobs where there are significant differences between builds due to e
.
g. parameters).
Unfortunately, this commit changed computation of build duration estimates:
https://github.com/jenkinsci/jenkins/commit/04d85eb476bdc57eb7ac3c2bb34e91be5b55c487
*Before:* Use the average of the last up to three successful builds. Use fewer if no three successful builds exist. If there are no successful builds, don't attempt to provide an estimate.
*Now:* Only look at the last six builds. Use the average of the last up to three successful builds of those. If there are fewer than three successful builds, also use the latest failed (but not aborted) builds to get three builds to base the estimate on. If three or fewer completed builds exist, use those.
So, if there's only one successful build among the last six builds, it will also consider the latest two failed builds for the estimate. *If there are no successful builds, use the build duration until previous build failures as estimate*.
Not going far back in the job history is a good idea to ensure computation is quick. Filling up the list of candidate builds with failed builds OTOH, is not.
----
*Taking into account failing builds makes the estimate completely meaningless.* It doesn't tell you anything, because the data it uses is all over the place (and it uses too few data points for more sophisticated estimates).
For a job that often fails after ~2-3 hours but takes 10 hours to complete successfully, this will often reduce the estimate to just ~5 hours. Even just considering one failed and two successful builds will result in an estimate of 7.5, which is way off the actual duration to get a successful build.
----
*Build failures should be considered exceptional conditions.* For non-fatal issues, builds can be marked unstable. *So failures should not be used in estimating build durations,* as some unreliable component used in a build will completely distort build durations.
Surprisingly, the change only considers _completed_ builds and excludes _aborted_ builds from the estimate. This respects the status of aborted builds as exceptional and unfit for build estimates (unless caused by the Build Timeout Plugin…). But failed builds are no more useful to build an estimate on!
I'd rather have it use the average of the last N (e.g. 3 or 5) _successful_ builds, and if there are fewer than M (e.g. 1, or 3), *just give no estimate at all.* For jobs that also have wildly varying durations for successful builds, it might actually be useful to not provide an estimated duration -- this would make it *explicit that Jenkins has no confidence in providing an estimate.*
|
|
|
|
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit
https://groups.google.com/groups/opt_out.
