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