-
Bug
-
Resolution: Unresolved
-
Minor
-
None
I use Test Results Analyser plugin to present the disponibility of my project.
The job launchs a SoapUI command which build a Junit report in a folder : workspace/report%buildNumber%/
So i use Test results Analyser to parse this folder/report.xml
The plugin is very useful to present a quick view of my differents features but now the access of the graph is very very long (about 30 secs) and the loading time is increasing with the number of builds.
Is there a way to limit this time or to reinitialize the datas computed by the plugin (the 50 last results for example).
Thank you for your help!
[JENKINS-42668] Tests Results Analyser Loading Time
Geoffrey Bourel
added a comment - Up for this problem.
Since my question the time for loading the page is now about 1min30s.
Is there any way to clean the history (which is not used in my project except for the last 50 results)
Thank you,
Geoffrey
Geoffrey Bourel
added a comment - Up for this problem.
Since my question the time for loading the page is now about 1min30s.
Is there any way to clean the history (which is not used in my project except for the last 50 results)
Thank you,
Geoffrey
We are having the same issue. We have multiple jobs with several thousand tests. When using the plugin on one of those jobs, it completely stalls the jenkins master. It is enough to cause an out of memory exception and bring down the jenkins master (32 GB of RAM).
I would like to suggest these improvements:
- Make it configurable if the plugin can be used on a job or not (JENKINS-36134)
- Make global configuration option in system settings, defining a max number of builds that will be used in the analysis, even when selecting "all".
- Create a cache of already parsed results, in a format that is less memory consuming and less disk intensive than parsing the original test results. (JENKINS-32205)
Per Böhlin
added a comment - - edited We are having the same issue. We have multiple jobs with several thousand tests. When using the plugin on one of those jobs, it completely stalls the jenkins master. It is enough to cause an out of memory exception and bring down the jenkins master (32 GB of RAM).
I would like to suggest these improvements:
Make it configurable if the plugin can be used on a job or not ( JENKINS-36134 )
Make global configuration option in system settings, defining a max number of builds that will be used in the analysis, even when selecting "all".
Create a cache of already parsed results, in a format that is less memory consuming and less disk intensive than parsing the original test results. ( JENKINS-32205 )
We have several thousand tests and suffer from the very long analysis. We mitigated that by configuring the plugin to only read the last 25 runs and that helps a lot but also is very limiting since we can't get a good idea of what are the top 10 flaky tests over a certain period of time, just the last few hours in our case.
I understand that this is caused by jenkins doing everything in XML and but I think the plugin could cache the data it has read from previous runs so that it can be a lot more efficient if the same report is requested twice or if most of the runs have been analyzed previously.
A workaround we are considering is to have a post processing pipeline that will collect the test results and recreate them with only the failing tests as a trick to have very small test reports to analyze. This post job would be used to get a more useful report. If we can do this trickery, certainly the plugin can do this internally.
We have just installed thiss plugin in our Jenkins.
The thing is that our build has almost 6 000 Junit tests.
When I clicked on the Test Results Analyzer link, the page doesn't stop to load, and Jenkins is taking all the available CPUs on the server (we have 8 cores).
How this report is generated ?
Is-it an on-demand build ?
If so, I guess it will never work for large projects.
For the record, I also tried to limit the number of build that are taken into account to 1.