|
||||||||
|
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.
If the build was manually started, the expectation is that the user fixed whatever was wrong.
Right. That's why I'd just exclude the 'failing' cluster.
It is not clear to me what the use case of the current behavior is. The previous behavior provided the duration of recent successful builds, which should most of the time be (close to) the longest possible build duration. Failures are likely to happen more quickly. Users could rely on the estimate to be close to the 'worst case' for waiting time and therefore being a safe estimate ("When will I have the artifacts?", "When will I be able to reboot Jenkins?", etc.).
The current behavior answers no question anyone could have, and it's not even obvious to users what the estimate is based on. Is it the latest three successful builds? No. Is it the latest three completed builds? No. It will, in most cases, result in a too short duration estimate, which can be really irritating.
Except that this isn't how it works. Don't get me wrong, just taking the latest three builds regardless of success, would be just as useless, but it'd at least be obvious how estimation works. Which it simply isn't right now.
Also, it doesn't consider that the project may have been reconfigured since the latest failure. Or that there were changes in SCM. And if the build was manually started, there's a good chance the issue was fixed.
Jenkins just doesn't have enough information to do a sophisticated estimate considering all these factors. In fact, the whole change was done to reduce the data required for an estimate. Any assumptions on the probability of failures are flawed.
Therefore Jenkins should simply adopt a behavior similar to the previous one: Estimate duration assuming the build is successful. And if there aren't enough successful builds to do that, it should just not provide an estimate at all. Forcing users to figure it out themselves (using build trend and possibly parameters and job config) if Jenkins cannot provide a useful estimate isn't a bad thing. At least it wouldn't misleading, like the current behavior.