Re: [boost] Feedback requested: Demo build server

From: Jason Sankey (jason_at_[hidden])
Date: 2007-09-27 01:12:54

David Abrahams wrote:
> on Fri Sep 14 2007, Jason Sankey <jason-AT-zutubi.com> wrote:
>> You may have noticed the discussion going on re: developer feedback 
>> systems.  As part of this I have just started setting up a demo build 
>> server at:
>>
>> http://pulse.zutubi.com/
>>
>> At this stage it is an early demonstration of the server (Pulse) 
>> building the boost trunk.  There is only one machine, but for 
>> illustration purposes I am running both the master and one agent on it. 
>>   This shows the ability to build on multiple agents in parallel (to 
>> test the different OS/compiler combos).  In this case I am testing two 
>> different gcc versions (the easiest to setup for the demo).
> 
> Very cool to see it working.  Sorry it's taken me so long to respond.

OK, I thought for a bit that enthusiasm had been lost.  There were a 
couple of quick and positive responses, though, and I'm glad you got a 
chance to take a look too.

<snip>

>> You might also notice the Pulse is kicking off a build when it detects 
>> any change, and shows the change information (also linked to Trac for 
>> diff views etc).  This should keep the machine busy, since a build takes 
>> over 2 hours (partly because two builds are running in parallel, but 
>> mostly just because the build takes that long).  Perhaps there is a 
>> shorted build/test cycle that should be run on every change for faster 
>> feedback.
> 
> I don't know how you're invoking the build, but if you're using
> regression.py, there is an --incremental flag you can pass that avoids
> rebuilding things whose dependencies haven't changed.

I am actually invoking things directly using Pulse.  Pulse checks out 
the source from svn and I use Pulse commands to run the build, in a 
similar way to how other testing scripts appear to work:

http://pulse.zutubi.com/viewBuildFile.action?id=1015903

I had some trouble figuring out the latest and best way to run tests, 
but this seems to work.

The default Pulse behaviour is to do a full clean checkout and build. 
However, there is an option to switch to incremental builds, where the 
same working copy is used for every build after an svn update to the 
desired revision.  The reason I steered clear is that I noticed a 
mention somewhere in the regression testing documentation that 
incremental builds were not 100% reliable.

As suggested elsewhere, breaking things down library by library would 
also help.  I have noticed a bit of discussion going around about this 
lately, and have to say that I think it would be very helpful for 
integration with Pulse.  Apart from faster builds, it would also make it 
easier to see the status of each library if it were a top-level Pulse 
project, and developers could then subscribed to email/jabber/RSS 
notifications for just the libraries they are interested in.

>> On the subject of feedback, you may also want to try creating an
>> account so you can log in.  Just click the login link (top right
>> corner) and you will see a link to sign up.  It is best to choose
>> your user name to match your Subversion user name, as then Pulse can
>> tell which changes are yours.  
>> Once signed up you get a dashboard
>> view along with preferences that allow you to sign up for email
>> notifications.
> 
> Oh, that is awesome!  I chose a different user name from my svn name,
> but then added an alias.  Will that work?

Glad you like it :).  Using an alias will work fine, that is what 
aliases were added for.

>> It would be great if people could take a look and let me know:
>>
>> 1) If you think this is useful and worth continuing with.
> 
> Definitely worth continuing with.  I don't think it's useful yet, but
> if you continue it will be.

OK, sounds good.

>> 2) What important features you think are currently missing.
> 
> Integration with the XML failure markup is the most crucial thing.

OK.  I need to understand these a bit better before I continue.  I am 
not sure at what stage in the process these normally take effect.  I 
guess a lot of the failures I am getting now are actually known and 
included in this markup?  I need to find some time to dig into this.

>> 3) How some of the errors/failing tests can be resolved.
> 
> Not connected to the 'net as I write this; I might be able to look
> later.

OK, thanks.  Getting to a state where a normal build is green will make 
things a whole lot more useful.

Cheers,
Jason