-
Bug
-
Resolution: Unresolved
-
Critical
-
None
Imported from GitHub: https://github.com/jenkinsci/jacoco-plugin/issues/12
Report by Greg Temchenko ("soid" on GitHub)
I broke down my Jenkins trying to use this plugin. It turned out that plugin stores the entire coverage in XML format in build.xml file in jenkins (JENKINS_HOME/jobs/[Project]/builds/[Build]/build.xml). Boolean values about covered/uncovered lines stored there as XML tags with indentation for readability
<boolean>true</boolean>
Thus my 600K code coverage .exec bin file consumed more than 700M on the hard disk for the build.xml.
This is a half of the problem. Further Jenkins keeps all builds information including mentioned above build.xml in RAM. That's how I've caught OutOfMemory exceptions in Jenkins and got it broken.
And a comment from Jesse Glick ("jglick")
For what it’s worth Kohsuke & I recently did some minor memory usage fixes in the Cobertura plugin, and I experimented with more: https://github.com/jenkinsci/cobertura-plugin/compare/master...trove
This issue makes the plugin forbidden to installation on JBoss Jenkins instance.
[JENKINS-16010] Plugin consumes too much memory
Ognjen Bubalo
added a comment - Jenkins serializes the objects with XStream into the build.xml. We need a bigger refactor, so we would not serialize the coverage objects, instead we would use maybe the Jenkins's new database plugin for storing.
Ref:
https://wiki.jenkins-ci.org/display/JENKINS/Database+Plugin
Ognjen Bubalo
added a comment - Jenkins serializes the objects with XStream into the build.xml. We need a bigger refactor, so we would not serialize the coverage objects, instead we would use maybe the Jenkins's new database plugin for storing.
Ref:
https://wiki.jenkins-ci.org/display/JENKINS/Database+Plugin 
Daniel Robinson
added a comment - I am having the same issue. The exececFiles are using 70Gb of disk space. Obviously a solution could be to limit the number of builds that are kept. But this would be a shame as the history would be lost.
Why do these execFiles folders need to be kept? Could a "simple" solution be to limit the number of builds for which these files are kept (from configuration parameter)?
Has anybody found a solution do automatically delete these files for older builds?
Daniel Robinson
added a comment - I am having the same issue. The exececFiles are using 70Gb of disk space. Obviously a solution could be to limit the number of builds that are kept. But this would be a shame as the history would be lost.
Why do these execFiles folders need to be kept? Could a "simple" solution be to limit the number of builds for which these files are kept (from configuration parameter)?
Has anybody found a solution do automatically delete these files for older builds? 
Hmm, this is not an easy issue. It will take a while..