announcing prototype buildbot<->bunsendb<->bunsenweb integration

[Frank Ch. Eigler]

Hi -

Not long after mjw's buildbot setup in April here on sourceware, we've
coupled to it a testsuite log file collection system.  This has now
reached a prototyping stage where it is more interactively browsable
and might become useful for actual test problem diagnosis.  Here's how
that stuff works:

0) sourceware has a buildbot master & a fleet of donated workers, as
   mjw announced over the last month or two, and here:
   https://gnu.wildebeest.org/~mark/sourceware.txt

1) most buildbot job steps include a bunsen_logfile_upload_steps() operation,
   which collects named log/sum/trs type files from the workers and
   pushes them into git://sourceware.org/git/bunsendb.git under a tag name
   that corresponds to the build

   https://sourceware.org/git/?p=bunsendb.git;a=blob;f=README  

2) a bunsendb.timer/.service job pair on sourceware regularly polls
   this git repository, and runs a bunsen processing pipeline to
   analyze all the logs and deposit results into an sqlite database
   file back on sourceware

   https://sourceware.org/git/?p=bunsen.git;a=blob;f=README;hb=refs/heads/fche/bunsenql

   /sourceware/projects/bunsen-home/bunsenweb/bunsenql.sqlite3 (on sourceware)
   /sourceware/projects/bunsen-home/bunsenql (bunsenql branch code checkout)

3) a bunsenweb.service job on sourceware activates the r-httpd-browse
   part of bunsen to let people use a browser to query / browse both
   the analysis database and the underlying log files.  This part is
   quite early, light on eye candy, will change rapidly.  But it may
   already be useful, so we're decloaking:

   https://builder.sourceware.org/testruns/ << entry point

   Some things to try.  All this is computed on the fly from the
   database, but most operations are surprisingly quick.

   - click on a testrun (row), observe the metadata associated with
     that testrun and the list of files, each of which may be viewed

   - experiment with the filter fields at the top to require presence
     of dejagnu .exp file names (ignore the automake trs stuff for now),
     or metadata; each uses sql LIKE pattern syntax for the operations
          https://www.sqlite.org/lang_expr.html#like
     e.g. https://tinyurl.com/43ntbsw2 to filter to some most recent
                          binutils-gdb gcc/clang rawhide full testsruns

   - click checkbox on two or more testruns to compare, hit "diff",
     getting a difference report between the runs
     e.g. https://tinyurl.com/2p88vu2h to compare some recent gdb builds

   - from there, observe the comparison grid; in each cell, links are
     generally given to the particular segment of the log/sum files
     where the test case failed/passed differently from its peers
     e.g. https://tinyurl.com/2p8evcca

   Lots of things will be coming here, including taking advantage of
   testrun cluster analysis that's already being done, a
   per-testrun testcase search/browse engine, other search operators,
   testsuite summary (vs detail) grids, who knows, ideas welcome!


Note that 2) and 3) can be also done independently on your own
workstation, if for example you git-clone the sourceware bunsendb.  Or
all of 1) 2) 3) if you have your own bunch of log files to import into
a whole separate installation.

The README files provide some instruction, and we'll have more man
pages before long.

- FChE