My first thoughts are to carve out the "compile", "nunit-test" and "regression-tests" into separate "cruise control builds".
The "compile" would use a sourcecontrol change as a trigger (or a timed interval). At the end of the compile, I would do 2 things [1]copy the compiled output to a known named folder. [2]write an empty text file of known name to that same named folder. The "nunit-test" and "regression-tests" would each use the filesystem-trigger to watch for that specifically named empty file (it may have to be in a subfolder). The first step of the nunit-test and regression-test build would be to take an independent copy of all the files from that "known named folder" into their own workspace and from that point you can run the nunit executable against the nunit specific working folder, and the regression test executable against the regression text specific working folder. (you don't want the "nunit-test" and "regression-test" build to start when only the first output file from "compile" has landed in that known named folder, which is why we have the empty file as the trigger) Make sure the nunit-test and regression-test builds are not in the same build queue and you should be good to go. There could be an easier way, but that's my first stab at it. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Joel Sent: Thursday, March 26, 2009 2:20 AM To: ccnet-user Subject: [ccnet-user] CC.Net, nUnit, MSBuild and BuildInParallel Hi, I am running CC.Net and everything is going well. Our code compiles relatively quickly but our nUnit tests take a long (very long - 20+ minutes) time to run. Further - we will be adding another tool to add on custom regression testing in the near future which will also be very time consuming (lots of financial calcs). So --- after the build - what is the best way to parallelize the nUnit and regression tests. We have roughly 23 dlls and the nUnit tests for each dll are 100% self-contained (or copies have already been made available to each testing location). So - in a perfect world - my IT department would spin up 23 processors and I would whip through the testing (I will assume that I get 2 or 4 processors - no IT department would ever give us 23 processors :) ). The regression testing is almost as easy to partition (a bit of copying and then off to the heavy lifting). My nUnit task currently looks like (it is simply a target in my MSBuild file that I call for compiling/testingfrom my ccnet.config file): config file: <project name="MainStream"> ... <prebuild> </prebuild> <tasks> <msbuild> <executable>$(msbuildexe)</executable> <workingDirectory>C:\builds\mainstream\CC\ArtifactDirectory</ workingDirectory> <projectFile>$(artifactDirectory_dir)\Netbuildscript.xml</ projectFile> <buildArgs> /noconsolelogger /v:quiet / l:FileLogger,Microsoft.Build.Engine;logfile=MyLog.log / p:VCBuildToolPath="C:\Program Files\Microsoft Visual Studio 9.0\VC \vcpackages"</buildArgs> <timeout>3000</timeout> <logger>$(msbuildlogger)</logger> </msbuild> </tasks> <publishers> ... </project> nUnit target from "Netbuildscript.xml" <Target Name="nUnitTest" DependsOnTargets="BuildTests"> <NUnit Assemblies="$(TestThisAgentInfo)\TestAgentInfo.dll; $(TestThisCalcDefaults)\TestCalcDefaults.dll; $(TestThisDataIO)\TestDataIO.dll; $(TestThisDataManager)\TestDataManager.dll; $(TestThisDiverse)\TestDiverse.dll; $(TestThisFormInfo)\TestFormInfo.dll; $(TestThisInputData)\TestInputData.dll; $(TestThisInputInfo)\TestInputInfo.dll; $(TestThisLogger)\TestLogger.dll; $(TestThisPageInfo)\TestPageInfo.dll; $(TestThisPageRender)\TestPageRender.dll; $(TestThisSessionManager) \TestSessionManager.dll; $(TestThisSymTab)\TestSymTab.dll; $(TestThisXML)\TestXML.dll; $(TestThisCalculations)\TestCalculations.dll; $(TestThisInit) \TestInit.dll; $(TestThisEDSDataMapper)\TestEDSDataMapper.dll; $(TestThisEval)\TestEval.dll; $(TestThisGuiManager)\TestGuiManager.dll; $(TestThisValidations)\TestValidations.dll; $(TestThisCore)\TestCore.dll; $(TestThisWebMessage)\FPWebMessage.dll; $(TestThisWebService)\FPReportMgrMain.dll;" ToolPath="$(nUnitPath)" DisableShadowCopy="true" OutputXmlFile="$(ArtifactDirectory)\nUnitResults.xml" ContinueOnError="true"> ... So - Assuming I get 2 processors (for now): Has anyone done this kind of thing before? What is the best way to approach this? Do I parallelize from CC.Net (can I???) or from MSBuild? If it is from MSBuild - is that easily done with nUnit (it seems easy to do with compile tasks ...nUnit parallelization... I cannot find much info) Any help is appreciated ... (and yes- I probably am missing something really obvious), Joel
