Attila Szegedi wrote: > ... >> Independently of the previous point, I'd like to help improving the >> quality of the project. With this I mean that the quality relies too >> much on knowledge of some individuals rather than on automated tests. >> I've already written my view on this and I still think that Rhino needs >> urgently a build system on which we can rely. For this purpose I've >> started to setup a Cruise Control instance for Rhino that is hosted by >> my friends of Canoo AG (http://www.canoo.com, they already host CC >> instances for HtmlUnit, WebTest, Grails, Groovy, ...). I can't yet post >> the url as the huge output produced by the StandardTests causes problems >> to CruiseControl and I have first to find a workaround. I can configure >> the build to post results to this mailing list if there is interest for >> it. Naturally the build fails currently as many tests fail :-( > > As a matter of fact, I secured an Atlassian Bamboo license to use with > Rhino, and got us provisioned a server managed within Mozilla > infrastructure more than a year ago for purposes of running it. I > believe I did announce it at one time or another on this list. It is at > <http://cn-rhino01.nl.mozilla.org:8085>.
I remember of it... but I don't think that I've ever seen anything working there :-( > I installed Bamboo on it and configured it to pull Rhino from CVS (also > a problem being that we can't just pull js/rhino module, we need to pull > js/tests as well, and Bamboo doesn't anticipate that, so we need to pull > js/* and filter out what we don't need; anyways...). with CC, I check out in 2 times (in fact 3 as I hold the config app from a SVN server) > The problem is, it regularly runs out of memory. The server (which is a > virtualized server, I believe) has 512M of RAM allocated, which I hoped > would be more than enough to build Rhino and run tests, but it > apparently ain't so, the standard tests indeed are a memory hog. Bamboo > is already set up to run with -Xmx512M (obviously spilling over to swap > when it reaches near that figure). I spent a weekend on trying to remedy > the situation, but didn't succeed. > > (I've just bounced Bamboo and now it runs the tests, you can check the > Activity tab... I'm afraid it'll however just drop the ball eventually > when it runs out of memory). > > Splitting up tests to run in separate JVM instances would probably help > even if it'd make everything much slower (not that it matters much with > a CI tool). Anyway, I can set you up an account on it (both the machine > and the Bamboo) if you feel like wrestling with this. I still think 512M > should be enough on the machine, and since it runs on a shared physical > Mozilla funded hardware, I'm reluctant to go and ask for more resources... thanks for the proposition. As I don't have any experience with Bamboo, I prefer to make it first working with Cruise Control. Once this work, it may be easy to have it working on Bamboo as well. I guess that the root cause of the problems are the huge xml reports. They have probably to be kept in memory until the tests finishes. A simple and elegant workaround would be to split the StandardTest. Rather to produce one huge report, it would be possible to follow the directory structure of the tests and have one report per directory (or even one per js test file). If you're interested, I can look at it but this isn't my first priority as I believe that it should be possible to configure CC to ignore the "real" logs. > Alternatively, if you get CC working and up, we can also just > decommission the Bamboo instance. ;-) Cheers, Marc. -- Web: http://www.efficient-webtesting.com Blog: http://mguillem.wordpress.com _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
