[V3dot10] Release team problems

[Keith Hodges]

Pavel Krivanek wrote:
> Hi Keith,
>
> It may be good idea to have both approaches - maybe in two different
> test servers - one for release building and the second for harvesting
> of patches from Mantis that are mainly in the form of changesets. Or
> one complex  sophisticated build&test system.
>
I had a quick look at your testing system again. I think that I used it 
for some inspiration in the beginning. This may be why it looks almost 
exactly the same in concept as mine, so I do not really think it is 
necessary to have two separate systems when they are actually so similar.

It is good to look at it again, there are some further ideas for me to 
see how I could simplify things a bit.

comparison:

download.py is a function for which I use ruby's rio library, 
downloading a zip file and extracting the image and changes file should 
in theory be a one liner with rio,

rio( 'http://server/image.zip' ).zip.each[ '*.image', '*.changes' ] >> 
rio('dir')

Except that this didn't work as expected and so I have to use the shell 
to execute unzip rather than rio's built in zip support.
 
The shell script in yours is a ruby script in mine. While yours is hard 
wired, mine takes arguments from the command line via a yaml file, or a 
wiki page with yaml in it. The arguments configure where to find the 
image, the vm and to collate the outputs in a formally defined structure.

You supply a script to run tests on a class called BooleanTest, I add 
functionality to SUnit in TestRunner, and a non GUI TestReporter class. 
My TestReporter output is a little more complex in that it provides a 
simple progress indication to the reader of the results file as it is 
being generated.

I simply add one byte per test to the progress file, giving remote users 
a progress indication, up until the 1000th test, then Apache displays 
the size in K, which ruins this nice simple plan.

I have a Launcher class for processing commandline arguments, you supply 
a script to the command line. When I run things with a script, my script 
loads the launcher class and lets it do its stuff, Launcher is intended 
to support, building, reporting, testing more building, and more 
testing, in one step if desired.

My SUnit stuff has lots of suite defining, categorising, selecting and 
filtering stuff in it too.

In practice now that I have a facility for triggering child-actions, 
multi-step processes can now be divided up into single steps. The test 
can be a child of the build, so in this case direct invocation of SUnit 
is the only step and so Launcher is not really needed to process 
multiple actions but it doesn't hurt.

Fixing AutoStart in KernelImage would give the same result, I have a 
refactoring of AutoStart sitting on my broken laptop which contains 
functionality equivalent to Launcher and tidies up all of the Auto 
updates stuff that you removed.

> To enable processing of arguments by the
> ernelImage we have to solve
> this issue http://bugs.impara.de/view.php?id=4849.
Hmm, my implementation does not rely upon AutoStart, I hook into it if 
it is there. I allow it to run a script at startup, and pass control 
over to my stuff from there.
> Few months ago I created this very simple test system:
> http://weeklysqueak.wordpress.com/2006/10/07/a-simple-squeak-testing-server/ 
>
> Its advantage is that it doesn't need direct support for test server
> in the image.
>
Agreed, that was also a requirement for my implementation.
> -- Pavel

Keith


	
	
		
___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html