Re: Beehive Check-in Test (Linux) Failed

16 Mar 2005 21:10:42 -0000


Agreed -- that's great for CruiseControl when the tests need to run to completion and then CC can detect pass / fail itself.

But, for developers on a local machine, the "grep" is performed by looking at the result of the Ant run -- not by scrolling up through the shell output looking to see if tests failed. If the run ends in BUILD SUCCESSFUL, that should mean something. :)

In NetUI, we deal with this by having a flag that describes whether we're running in CruiseControl mode. Check out the file:

  trunk/netui/test/ant/testRecorderCore.xml

which uses the "cc.mode" flag to determine whether to fail the run when tests fail.

  Let me know if you've got questions.

Eddie



Joe Pemberton wrote:
From what I understand, the reason the test run does not fail early 
there is that for a CruiseControl run, it is useful to do the full test
run (and not fail early if the controls tests have errors).  After the
full controls test build/run, CC greps for "BUILD FAILED", and fails the
build accordingly.

James may know more about this..

-Joe



-----Original Message-----
From: Eddie O'Neil Sent: Wednesday, March 16, 2005 12:58 PM
To: Beehive Developers
Subject: Re: Beehive Check-in Test (Linux) Failed


   My take is that those three test aborts should have failed the entire

Ant process at the point where the controls tests failed.

Without that, the tests fail and the build continues, and the Ant process can still end in BUILD SUCCESSFUL even if there were aborts.

   Probably good to follow the JUnit / Ant model here -- fail early.

   :)

Eddie



Joe Pemberton wrote:

Eddie,
I'm not sure I follow you.  I see the three aborts in the TCH run,


and

I see a BUILD FAILED at the end of the run.  Also, the CC run itself
failed.

-Joe

-----Original Message-----
From: Eddie O'Neil Sent: Wednesday, March 16, 2005 10:45 AM
To: Beehive Developers
Subject: Re: Beehive Check-in Test (Linux) Failed


A second-order problem is that there are three tests in the TCH

test

suite that were aborted (and even stack traced), but these didn't fail


the controls test suite. Look at this link and scroll down to the TCH 


output:

  http://beehive01.bea.com/downloads/20050316052618/general/build.out

Zach, can you take a look at this? We saw the same thing with some 


controls test failures last week.

Eddie



Daryl Olander wrote:


So it appears that there is a break in the controls checkin tests that
was caused by the same checkin from this morning.


http://svn.apache.org/viewcvs.cgi?rev=157742&view=rev

CC was broken at 5:26 this morning.  There were two sets of failures,
the WSM Drts failed in addition the  controls check in test failed

http://beehive01.bea.com/downloads/20050316052618/controls/tch.cout

There is only a single checkin here.


On Wed, 16 Mar 2005 10:33:09 -0800 (PST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:



View results here -> 


http://beehive01.bea.com/cruisecontrol/buildresults?log=log2005031610210

0





Reply via email to