Re: [boost] Feedback requested: Demo build server

From: Jason Sankey (jason_at_[hidden])
Date: 2007-09-14 09:09:30

John Maddock wrote:
> Jason Sankey wrote:
>> Hi all,
>>
>> 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:

<snip>

>> 1) If you think this is useful and worth continuing with.
> 
> Definitely.

Thanks for the vote of confidence :).

>> 2) What important features you think are currently missing.
> 
> I found navigation a tad tricky at first: it would be useful if I could get 
> to "all the failures for library X" in the last build directly and easily. 
> As it is I had to drill down into the detail report and then scroll through 
> until I found what I was after.  Or maybe I'm missing something obvious? :-)

You are not missing anything, the drilling is necessary at the moment. 
This is largely because of the structure of boost, where all libraries 
are built in one hit.  Hence they are all currently in one Pulse 
project, and the result set is large.  One possible solution is to have 
a view of tests organised per suite (in Pulse terminology: each library 
is grouped into one suite) rather than the current view which is 
organised by stage (another Pulse term which refers to a single run on a 
specific agent).  It is also possible to capture HTML reports and serve 
them up via Pulse, so the build process itself could generate different 
types of reports as necessary.  Pulse supports permalinks to such 
artifacts so you could always find the latest report at a known URL.

> Can you explain more about the "My Builds" page and what it offers, as it 
> looks interesting?

This page shows you the results of your "personal" builds.  Personal 
builds are a way for you to test outstanding changes before you commit 
them to subversion.  Basically, you install a Pulse command line client 
on your dev box.  Then, when you have a change ready to commit, instead 
of running "svn commit" you run "pulse personal" and your change is 
packed into a zip and uploaded to the Pulse server.  Pulse checks out 
the latest source, applies the changes and runs a regular build and test 
(possibly on multiple agents).  If the build passes you can commit with 
confidence; if it fails you can fix it and no other developers have been 
affected.

This is a feature that really comes into its own when you need to test 
on multiple environments.  Developers usually don't have an easy way to 
test all environments, so would usually just commit and find they have 
broken some other platform later.  IMO it would be a great tool for 
boost developers, but there would be challenges:

1) Having enough machines available to cope with the load of both 
regular and personal builds.
2) The long build time.  This could be mitigated if just the library of 
interest was built, which is possible if we configure recipes in Pulse 
for each library.

> Nice work, John Maddock.

Cheers,
Jason