Test server

I'm trying to set up a test server, as requested by lsantha.
It's an AMD Athlon64 3500+ single core, but with hardware virtualization. I put 2 GB RAM into it.
I am installing Ubuntu 8.10 Server AMD64 on it, and run JNode in a KVM virtual machine.

I am starting the virtual machine with
kvm -m 512 -std-vga -no-acpi -no-kvm-irqchip -hda jnode.img -boot d -net nic,model=rtl8139,macaddr=... -net tap -vnc myhostname:1 -cdrom jnode-x86-0.2.7.iso

I have network in JNode after manual configuration, and can access a (virtual) harddrive as hda0. I can run the mauve test suite, thanks to lsantha's help.

I set up a web server on my public server to publish the test results. (Running an http server in my private network - including in JNode - is not an option, for the sake of my security.) The results from the manual run are uploaded, but they're not terribly useful yet, as it's still JNode 0.2.7.

(Read on what still needs to be done)

I found a number of bugs in JNode on the way, and filed them in the bug tracker.

Currently, I am fighting with Ubuntu on the actual test server, because it fails to install GRUB.

We need something that controls and runs the tests - I hope for help by others here. I imagine something like:

trigger = every 15 minutes
svn checkout
check if something changed. if not, exit
check that there's a previous run running. if so, exit.
build (with source modifications for jnode.ini etc.)
if there is a build error, upload that and exit.
run kvm with iso built and premade harddrive image, see command above
inside JNode, jnode.ini starts test suite and powers off machine via halt
if the VM/JNode hangs (monitor it), kill it.
find out when the machine powered down (given that ACPI powerdown does not work). E.g. via JNode kernel logging on serial console, and kvm -serial file:kernel.log
mount the virtual harddrive for jnode on host machine
upload test results to server
umount virtual harddrive

Ben Bucksch's blog
Login to post comments

Trigger interval

Submitted by Peter on Wed, 12/31/2008 - 14:17.

Hi Ben,

nice to see someone working on the automated tests.
I want to make some comments to the trigger interval. Imho one test run a day or even less is good enough. After each update you'd need to make a clean build (else you couldn't be sure a bug is a regression) which takes some time, you'd need to run the test suite which takes much time. In the future you'd perhaps run the 32bit build, then the 64bit build, using different gcs,.. This all takes so much time that regular tests (as in multiple times a day) would not be working.

Regarding point 9/10. We once had the idea of a "heart beat server" to monitor from the outside if JNode is still alive. I'm not sure but I thought Fabien put some work into that. Fabien?

And FYI I'd like to point you to this page, a tool to compare two mauve runs and to this tool for pre-build configuration of JNode. Imho both should be included in your list/working plan above (at least for a "final" version).

better solution : hudson + JTestServer

Submitted by Fabien D on Wed, 12/31/2008 - 17:26.

For the trigger thing, there is a far better solution : using the hudson continuous integration server. It's very easy to setup (it can be installed in apache tomcat).
With hudson, we can trigger a build both when svn changes occured or on regular basis (like a nightly build), run whatever we want like automatic tests from an ant script, a maven script or even a shell script. I have already discussed that with lsantha and he agreed it's a good idea to use hudson.

For points 7 to 10, there is a tool that I called JTestServer that will do that. I will document that tool here as soon as I have time.

Fabien

my blog : en français, in english or both