|
||||||||
|
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
There is no argument about the desirability of showing a trend past a few deleted builds, only the best way to implement that without regressing performance. Someone (perhaps myself) needs to spend a couple hours creating a test asserting that the number of additional build records loaded by virtue of displaying the trend graph (relative to what is shown in the Build History widget anyway) is zero or small, so that an alternate algorithm can be picked to decide which builds to include.
(JENKINS-24380 may make it possible to introduce a core API for cheaply determining whether a build of a given number is supposed to exist without actually loading it; if so, this would be an attractive choice, though it would require a dependency on a post-LTS core release. TBD.)
As an aside, Peter Winkler I think your use case would be better served by using the “skipped” status of test cases/suites. This records the fact that the build did run (at a certain time, with a certain changelog, etc.), and records what tests did run to completion—passing or failing—as well as recording which tests were omitted from the suite, or started to run but were killed due to some transient problem with the environment.