|
||||||||
|
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.
Obviously the logged data is highly redundant. And this bug has been fixed before. The actual output of the job is only a few KB so exploding it to hundreds of MB is a serious misuse of resources.
Our Jenkins deployments have tens of thousands of jobs which have a lot of downstream dependencies between them.
The longer these dependency chains get to longer and more redundant the output gets. It does not only scale linear with the dependency hierarchy but exponentially because of the many repetitions of the same dependencies.
(Why are we doing that? Each job build a certain Debian package and afterwards triggers its downstream dependencies since we can not guarantee ABI stability. )
The example job is one of the many but each and every job has the same problem. The deeper in the dependency graph the more severe the problem is. Since we trigger these jobs multiple times per day that results in a lot of GBs of unnecessary data which keep growing with every job we run and the master has to keep them.
We don't want to truncate the number of kept builds because we value the information available in the (useful part of the) build log. We also can't provide unlimited fast storage to the master.