-
Bug
-
Resolution: Unresolved
-
Major
-
None
We have fairly complex build process where each build produces 400 jacoco exec files which are total of 80MB, in addition of exec files jacoco is also keeping snapshot of source code and class files which is drastically increasing the cost for keeping historical build which we all want to keep.
Jacoco plugin should make it configurable to persist old Java/Class files or not, as generating trend chart shouldn't require keeping the entire data set but trend chart can be generated incrementally, as most people wouldn't need to go and analyze older code coverage reports.
[JENKINS-27297] Using jacoco is drastically increasing Jenkins historical builds folder size
Tobias Gruetzmacher
added a comment - This should probably be coupled with the BuildDiscarderProperty (especially artifactDaysToKeep and artifactNumToKeep)
Tobias Gruetzmacher
added a comment - This should probably be coupled with the BuildDiscarderProperty (especially artifactDaysToKeep and artifactNumToKeep) Each file is stored multiple times:
./WebSocketClientMessagingProvider.java ./executor/WebSocketClientMessagingProvider.java ./agent/executor/WebSocketClientMessagingProvider.java ./sf/agent/executor/WebSocketClientMessagingProvider.java ./applications/sf/agent/executor/WebSocketClientMessagingProvider.java ./itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java ./spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java ./com/spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java ./src/com/spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java ./com.spirent.itest.applications.sf.agent/src/com/spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java ./plugins/com.spirent.itest.applications.sf.agent/src/com/spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java ./clister/plugins/com.spirent.itest.applications.sf.agent/src/com/spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java
Vasili Gulevich
added a comment - - edited Each file is stored multiple times:
./WebSocketClientMessagingProvider.java
./executor/WebSocketClientMessagingProvider.java
./agent/executor/WebSocketClientMessagingProvider.java
./sf/agent/executor/WebSocketClientMessagingProvider.java
./applications/sf/agent/executor/WebSocketClientMessagingProvider.java
./itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java
./spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java
./com/spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java
./src/com/spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java
./com.spirent.itest.applications.sf.agent/src/com/spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java
./plugins/com.spirent.itest.applications.sf.agent/src/com/spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java
./clister/plugins/com.spirent.itest.applications.sf.agent/src/com/spirent/itest/applications/sf/agent/executor/WebSocketClientMessagingProvider.java
Justin Rodante
added a comment - Heavily affected my team's work as well, we are having to hack around this with jobs to go through any build with jacoco folders and purge files older than X.
Would love an update on this as this issue been open for almost 6 years at this point
Justin Rodante
added a comment - Heavily affected my team's work as well, we are having to hack around this with jobs to go through any build with jacoco folders and purge files older than X.
Would love an update on this as this issue been open for almost 6 years at this point 
Agreed.
Also, similarly to other plugins dealing with large reports, there should be an option to only preserve the full report for the (few? configurable?) last (successful?) build(s). There is usually no need to preserve the complete history of JaCoCo detailed coverage reports, though the trend is evidently important. So this would have the advantage of keeping the size fo the builds folder stable and manageable.