On 2/23/12 9:04 AM, Nicolas Bros wrote:
what does keeping JUnit test results in memory mean?
I assume it only keeps the Junit test report XML files chosen
in "Publish JUnit test result report" in the job configuration.
These can get big when the tests output a lot of text
(stacktraces, log messages etc.)
Yes that is correct. To know exactly look at the XML file hudson
creates at <job>/builds/<build-no>/junitResult.xml. If
this file is large, then it is going to consume more memory.
On Thu, Feb 23, 2012 at 5:52 PM, Ed
Exactly what does keeping JUnit test results in memory mean?
For the MDT/OCL JUnit tests, the derived TestCase classes
have fields that can reference useful and sometimes large
models. These used to be a major source of 'leakage' and
sometimes prevented tests running in 512M. After making sure
that all fields were nulled in tearDown() they run in 32M.
GMF Tooling uses MDT/OCL, so they may be encountering a
similar form of model lock-in.
After the build is done, Hudson keeps some of the build
artifacts such as JUNit or maven metadata info. Since
hudson keeps all the builds of all joba, this bloats up
the memory. The immediate solution is reduce the foot
print of these build artifacts, if we can. Long term
term solution is fix Hudson not to keep all the builds
cross-project-issues-dev mailing list