I am using Apache Continuum as a continuous integration server to test Netty, the Java NIO Client Server Network Application Framework.
I’m pretty satisfied with the CI server since it’s running more than 1000 Netty test cases about 4000 times a day with 7 different JDKs (see the live report here). It increases the chance for me to catch a hidden race conditions which might cause a problem in a production environment. I actually was able to find a couple critical issues like a dead lock thanks to the intensive automated testing.
However, the caveat of running big number of tests a day is that too many build results are filed into the build report database, slowing down the overall performance of the CI server. Moreover, Continuum doesn’t provide the paginated view of build results at this moment, and therefore the large number of build results can lead to high memory footprint and poor UI response time.
So, I ended up with a simplistic tool that removes the successful build results which are older than the certain amount of time (e.g. 6 hours). Continuum provides an easy-to-use client API which is based on XML–RPC, so it didn’t took long.
I run reap-old-builds command every 10 minutes to keep the build result set as small as possible, and now Continuum is responding much faster than before. If you are interested, please check my latest work from the following Subversion repository:
- https://t.motd.kr/repo/svn/continuum-tools/trunk
cool 🙂
Have you tried using the scheduled purge of build results that is available in 1.2.2?
@Brett Porter: Hey! How are you doing? 🙂
I thought the purge configuration there is only about directories and repositories? Am I missing something?
Why not use Hudson? It has two purge process by default:
1. Keep only last x builds
2. Delete builds that are older than x days.
With Hudson’s matrix build feature, you could create one build with matrix of 7 different JDKs so you have consolidated view of all builds in one place.
@Prabhat Jha: Yes, I know Hudson has more useful purge configuration. Also, Hudson seems to be much better in task queueing. However, its Web UI doesn’t appeal to me. 🙂