[buildd-tools-devel] [PATCH] buildd: Get detailed build status and stats from sbuild

[Roger Leigh]

On Sat, Nov 13, 2010 at 04:16:54PM +0100, Philipp Kern wrote:
> Hi there,
> 
> On Sat, Nov 13, 2010 at 03:01:24PM +0000, Roger Leigh wrote:
> > I've attached a proof of concept patch to pass back detailed
> > information about a build to buildd from sbuild.  At the end of a
> > build, sbuild prints RFC-822-style text to stdout detailing
> > build state, failure cause (if any), and information about the
> > package, statistics about the build etc.
> > 
> > Currently, buildd knows little about what goes on; it just gets the
> > sbuild exit status, which is either 0, 1, 2 or 3 depending upon the
> > build status and failure stage.  It's not particularly extensible or
> > flexible.  With this patch, all this information is passed back
> > directly, so buildd can make more informed decisions based upon this
> > information.  With this patch, the behaviour is exactly the same as
> > with the 0-3 return codes, but this could be extended to be more
> > intelligent.
> 
> what would be on stdout (and not on stderr instead) that's not stats,
> given that we use `--batch'?  I.e. why do you need those markers
> in the first place, instead of just printing stanza after stanza?

Well, I thought sbuild wasn't issuing any output, but this made me
less sure:

    #We want to collect the first few lines of sbuild output:
    my ($sbuild_output_line_count, @sbuild_output_buffer) = (0, ());
    while (<SBUILD_OUT>) {
	#5 lines are enough:
	if (++$sbuild_output_line_count < 5) {
	    push @sbuild_output_buffer, $_;
	}
    }

If sbuild isn't doing any output, why are we storing it in
@sbuild_output_buffer?  We do need to read it so sbuild doesn't
block, whether it outputs or not, but this made me less sure.

I've just extended this block to capture the additional output.

Regarding reading multiple stanzas, this would be ideal.  It is also
a prerequisite to re-enabling running sbuild in batch mode with
multiple packages so it can get the build status for each one.

> Why don't we still exit with the exit code?

There are two types of failure to cater for

1) A failure in sbuild itself, due to e.g. configuation error, bad
   command-line options, hitting a die statement or some actual bug
   in one of the modules.
2) A build failure, e.g. failure to satisfy dependencies, failure
   to download source, failure during build etc.

Using the exit status codes for both failures is possible, but is
using the same mechanism to report two separate things.  Should a
build failure translate to a nonzero exit?  Historically, buildd
treated a nonzero return as failure in sbuild only; build failures
returned nonzero.  We added nonzero return on build failure in
"user" (not buildd) mode due to demand for it.

BTW, batch mode is one place where the package status does not make
sense to have in the exit status: each separate package can have a
different build status, so a single number is useless while we can
pull all that out of the RFC822 blocks.

I'm not against keeping it, but we should probably then just report
the same error values in both user and buildd mode--there's little
justification for the different behaviour now that buildd can
accept nonzero status.  I can add that back, that's no problem,
though we would need to decide how to handle return values in
batch mode where you may have multiple successes and multiple failures
in a single run to deal with.

> The RFC822-style interface is a nice idea that could just be placed
> on top of the current mechanism.  And I fully agree that the build
> meta information should be passed through a RFC822 interface.
> (Although we currently take that information from the mailed
> build logs anyway, the stuff you changed is only summarized and
> mailed to the buildd admin periodically.  The syntax within the mailed
> build logs *must* stay the same, though.)

Which tools are currently dependent upon parsing the current log
format?

Also, what information do they need from the log?  I'd like to
put all the extractable information into this metadata.

I've added the same RFC822 output to the end of the build log as well;
it could even be added at the top of the mailed build log or even as
a separate MIME part in a mail.

It would be nice to convert the existing tools to utilise this
information, or even get buildd to handle it directly when possible.
It will make our system somewhat more robust, not to mention easier
to extend in the future.  And we then know that changes to the log
output won't break anything.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101113/ed93dd92/attachment-0001.pgp>