Repository navigation
[JENKINS-1246] Trend graph still shows very long build after delete #13885
Description
hudson ver 1.176
seamonkey 1.1.7 on winxp
Problem:
my builds typically take about, say 10 minutes.
one build (for whatever problem) takes 10 hours, which in turn makes the
"trend graph" looking nasty.
- deleted that one long build
- it's then no longer on the lists visible (neither on the "build history" on
the left of the page, nor on the list below the graph. - BUT: it is still shown on the graph.
Note that I assigned P5 .....
Originally reported by gerhard6, imported from: Trend graph still shows very long build after delete
- status: Closed
- priority: Trivial
- component(s): core
- resolution: Fixed
- resolved: 2008-03-04T17:43:31+00:00
- votes: 0
- watchers: 0
- imported: 2025-11-24
Raw content of original issue
hudson ver 1.176 seamonkey 1.1.7 on winxp
Problem: my builds typically take about, say 10 minutes. one build (for whatever problem) takes 10 hours, which in turn makes the "trend graph" looking nasty.
- deleted that one long build
- it's then no longer on the lists visible (neither on the "build history" on the left of the page, nor on the list below the graph.
- BUT: it is still shown on the graph.
Note that I assigned P5 .....
- environment:
Platform: All, OS: All
Activity
jenkins-infra-bot commentedon Feb 2, 2008
Raw content of original comment:
On a related topic, Hudson should probably choose the Y-axis value range more
wisely, so that those out-of-proportion values wouldn't mess up the entire graph.
jenkins-infra-bot commentedon Feb 2, 2008
Raw content of original comment:
For example, Chebyshev's theorem
<http://en.wikipedia.org/wiki/Chebyshev%27s_inequality> states that 96% of the
data would be within 5-stddev range from the average, so maybe we can choose the
maximum Y-value as "min( maximum data value, average + 5xStdDev)"
jenkins-infra-bot commentedon Mar 4, 2008
Raw content of original comment:
Implemented in 1.188.