From: Clayton H. <cla...@sp...> - 2004-02-27 16:11:59
|
Hi, I think reporting on which targets/projects passed and failed would be a great idea, maybe with an indication of whether this failure is "alright" as defined by the build script. =20 I am not so keen on adding try/catch blocks to build files though. In my mind attempting to catch and recover from a build failure during a build just seems like it could get way to messy and in my mind would add some uncertainty about the results. =20 I think it would be better to keep it as close to a pass/fail outcome as possible and just provide enough information about what failed and why to help the local build meister fix it for next time. Clayton > -----Original Message----- > From: Randy Regnier [mailto:reg...@pr...]=20 > Sent: February 27, 2004 7:42 AM > To: 'Martin Aliger'; 'Nicklas Norling'; 'Gert Driesen';=20 > nan...@li... > Subject: RE: [nant-dev] 2 small changes to consider >=20 >=20 > Our group approached this problem by adding capability to the=20 > nant task that allowed a nested nant call to set values for=20 > properties that were then available to the calling client.=20 > When tests fail for some project, we add the name of the=20 > project to the property, which then gets displayed at the end=20 > of the build, such as: >=20 > "Tests failed in projects: x, y." or > "Built projects: a, b, c." >=20 > Randy >=20 >=20 > -----Original Message----- > From: nan...@li... > [mailto:nan...@li...] On=20 > Behalf Of Martin Aliger > Sent: Friday, February 27, 2004 9:20 AM > To: Nicklas Norling; 'Gert Driesen';=20 > nan...@li... > Subject: Re: [nant-dev] 2 small changes to consider >=20 > Hello >=20 > > > > 1) Multiple files: Added a project level variable called > > > > nant.project.failure, such that a you can allow a task or > > > group of tasks > > > > to complete regardless of failure using failonerror=3Dfalse, and > > > > then afterwards check the value of nant.project.failure to=20 > > > > determine if a failure occurred. Very useful for batch nunit=20 > > > > tests, and gathering a report of the tests before checking if a=20 > > > > failure occurred > > > and throwing a > > > > fail. >=20 > > This points out a gap in nant as I see it. What Jeff has=20 > made a patch > > for is actually a pretty large gap in functionality in nant. > > Controlling the flow using failure detection and also log=20 > that neatly=20 > > for other tools to pick up (CCNet comes to mind) is=20 > challenging to say=20 > > the least. >=20 > Agree. And one global property is not general solution. It is=20 > just the flag > - it didnt say why it failed, how many tasks failed, etc. >=20 > The same matter I tried to solve with inter-task=20 > communication I presented some time ago. So you could give=20 > task failonerror=3Dfalse and then check resulting "output" from=20 > task what is done, what fails etc etc. >=20 > <trycatch> task is another possibility. Maybe they could=20 > exists both and catch block could get "output" from failed=20 > task to examine why it fails. >=20 > Regards, > Martin >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with a free=20 > DVD software kit from IBM. Click Now!=20 > http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438> &op=3Dclick >=20 > _______________________________________________ >=20 > nant-developers mailing list nan...@li... > https://lists.sourceforge.net/lists/listinfo/nant-developers >=20 >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now!=20 > http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438> &op=3Dclick >=20 > _______________________________________________ >=20 > nant-developers mailing list nan...@li... > https://lists.sourceforge.net/lists/listinfo/nant-developers >=20 |