On Tue, Jun 23, 2020 at 7:18 PM Jesse Glick <[email protected]> wrote: >> reloading of previous builds is quite expensive > > There is not really a workaround
I should clarify that you _can_ load historical results without triggering disk I/O, if they happened to be in memory anyway, which the test trend graph does: https://github.com/jenkinsci/junit-plugin/blob/bab34bcc96154a494f8c371953efe06d45813f67/src/main/java/hudson/tasks/test/AbstractTestResultAction.java#L341-L346 https://github.com/jenkinsci/junit-plugin/blob/bab34bcc96154a494f8c371953efe06d45813f67/src/main/java/hudson/tasks/test/AbstractTestResultAction.java#L218-L225 The issue is that you cannot efficiently query historical builds without forcing them to be loaded—there is no equivalent of a SQL statement you could run to get some aggregate statistic over thousands of builds that would perform tolerably. So if the last five builds are in memory (a typical situation forced by the weather list view column), you can cheaply inspect those five, but inspecting the one before them will be expensive. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1qhbaPH1LRZbdiP8AB26qTD06QxWf%2BsQmK96mMNm_pww%40mail.gmail.com.
