[petsc-dev] Nightly tests quick summary page

[Karl Rupp]

Hi Jed,

 >     Dear PETScians,
>
>     I've adopted the HTML summary page script for the style checks a
>     little in order to have a quick overview of the results of our
>     nightly tests:
>     http://krupp.iue.tuwien.ac.at/__petsc-test/
>     <http://krupp.iue.tuwien.ac.at/petsc-test/>
>     It doesn't do anything fancy, particularly no automatic bisection or
>     the like, but it gives an overview of the Nightly results in seconds
>     (which are not overly good at the moment...).
>
>
> Cool, that's already very useful. Presumably the Error and Warning
> labels are backward in the Examples table.

A quick overview about the current state/health of petsc-dev was one of 
the things I missed most when I joined the group :-) And yes, the labels 
are messed up, thanks for reporting.

>
>     Assuming that there is no question about the need for improving our
>     current automatic testing environment, it's merely a question of how
>     far we want to go. Regarding overall productivity, I made good
>     experiences with just using CTest and setting the summary page as
>     the start page of my browser. It's not overly complicated an can be
>     integrated with reasonable effort into our CMake build system.
>
>     We could also do all the fancy things provided by continuous
>     integration systems. Sadly, I don't have any experience on that
>     front. Regardless, I still prefer rather simple systems which are in
>     daily use and fairly robust rather than a complex,
>     it-can-do-anything-for-you-if-__you-find-the-right-switch system
>     that is never set up...
>
>     Any thoughts/experiences? I know Jed has good plans on a testing
>     environment, so this is not meant to be an assault on him ;-)
>
>
> Not in the least. I had grand plans, wrote some code, ran out of time,
> and it drifted to the back burner. Hopefully I can get back to it, but
> it's not likely to overlap too much with what you're doing. (But let's
> talk if you want to do something intrusive that will depend seriously on
> the way tests are run or the way output is tabulated.)

All I need for this type of quick summary is to have some means of 
detecting warnings or failure. Ideally the tests report failure via the 
return type. Otherwise one can usually still wrap everything into a 
script which then provides the respective output. I don't think anything 
intrusive is needed, but I may know too little about how things are 
handled at the moment.

Best regards,
Karli