public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Mark Wielaard <mark@klomp.org>
Cc: Kris Van Hees <kris.van.hees@oracle.com>, frysk@sourceware.org
Subject: Re: Automated build-and-test summary report (2007/11/05)
Date: Tue, 06 Nov 2007 13:45:00 -0000	[thread overview]
Message-ID: <20071106134446.GE10486@oracle.com> (raw)
In-Reply-To: <1194351776.3855.31.camel@dijkstra.wildebeest.org>

On Tue, Nov 06, 2007 at 01:22:56PM +0100, Mark Wielaard wrote:
> OK, so "First failure:  no changes - not built" actually means that the
> sources didn't change from the last time the builder ran and so it
> wasn't build. Correct? If so the "First Failure" part confused me.

Yes, in the email report the first failure entry actually gives the first
stage in the build-and-run instance where a failure was detected.  There are
actually three possible entry types here (both for the current result and for
the previous result):

	- no failures: this obviously is a rare entry, because it means that
		all stages completed without any problem
	- no changes - not built: this is reported when there were not changes
		found in the source tree during the build-and-test run; labrat
		doesn't perform a build/test run unless at least something in
		the source tree changed
	- a stage name: the most common case, reporting the first stage that
		failed

I guess it can be a bit confusing in cases like:

	First failure:  test (was no changes - not built)

especially because it might (incorrectly0 read as if the (was...) part is
actually an explanation of why 'test' was the first failure, rather than
reflecting the previous state (result of the previous build we're comparing
to).

Would it be more clear if I changed that to be:

	First failure:  test (previously: no changes - not built)

> > The fact that the (usually) downloadable logs are not being shown as links
> > (that section is empty) is a bug.  I'll send notice when it is resolved.
> 
> OK, yes, that was the other confusion.

Being worked on right now.  The nice part of task separation is that one thing
failing in the reporting engine won't stop the rest from work.  The less nice
part of task separation is that if one thing in the reporting engine fails and
the rest keeps working, it is not necessarily noticed (by me) that there is a
problem :)  Win a few, lose a few.

	Cheers,
	Kris

  reply	other threads:[~2007-11-06 13:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20071105140036.GA2015@oracle.com>
2007-11-06 10:25 ` Mark Wielaard
2007-11-06 11:42   ` Kris Van Hees
2007-11-06 12:23     ` Mark Wielaard
2007-11-06 13:45       ` Kris Van Hees [this message]
2007-11-06 15:03         ` Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071106134446.GE10486@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=frysk@sourceware.org \
    --cc=mark@klomp.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).