harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [buildtest] moving the testing infrastructure forward
Date Tue, 21 Nov 2006 02:00:22 GMT
The basic idea is to have a testing framework of 'builders' that just do
the dirty work and send the results to a centralized location that does
analysis and presentation.

We currently have a seed of this at


The theory is that you do

 > svn co https://svn.apache.org/repos/asf/harmony/enhanced/buildtest/trunk/
 > ant setup (this gets all the stuff you need and compiles everything)
 > ant (this starts cruisecontrol)

you can do it on your own machine, you can run it continuously or simple
one every other day, you can run it virtualized or not, doesn't matter.

The problem is that the practice doesn't meet the theory, so let's try
to fix what's wrong with the current implementation:

1) the config-full.xml is OS independent but it's not ARCH independent
(it's currently frozen to i32). This needs to be fixed.

2) cruisecontrol starting scripts are really ugly and the README
suggests that you patch them before you start. This should be done
automatically during 'ant setup' using a <replace> task (or by providing
our own startup scripts for CC which is not that hard)

3) if we allow every single CC instance to send email to this list we'll
be flooded. I think we should turn that off and implement our own
'publishing' plugin for CC that publishes the results to harmonytest.org
(which should redirect to harmony.zone.apache.org as soon as we can). It
should be the receiving end to send email to the list in case shit
happens (providing a summary of the results).

4) we should *NOT* add things like japitools or findbugs to this testing
environment as only things that are 'OS/ARCH' dependent are useful in
this distributed testing. Anything that has to do with static analysis
can be performed in a centralized location more efficiently.

5) config-full.xml currently runs three targets "classlib, drlvm and
drlvm-test" where classlib runs the build and runs the tests. I think
classlib should be split in three: java, native and tests. I also note
that classlib tests need a JVM, so we need to come up with a reasonable
strategy for all that.



View raw message