CruiseControl.NET merge nunit and nant output

Question

I've just started using ccnet so I'm having trouble understanding why the merging of nant and nunit outputs are not working. I've setup my ccnet.config with typical values as found on google:

<merge>
<files>
<file>D:\ccnet\path1\nant-results.xml</file>
<file>D:\ccnet\path2\TestResult.xml</file>
</files>
</merge>
<xmllogger /> 

Nant and ccnet are half working: if I deliberately put in a code error, then ccnet will say build failed. The same happens if I deliberately put in a failing test, ccnet will say build failed.

But the ViewBuildReport.aspx page does not show any of the output from nant or nunit.

Obviously I must be missing something, but I don't know what, any ideas?

Thanks,

JK

Answer 1

Is that block located in your publishers section?

Here's what one of my publishers looks like:

    <publishers>
        <merge>
            <files>
                <file>*-results.xml</file>
            </files>
        </merge>
        <xmllogger />
    </publishers>

Answer 2

I had missed the publishers tag, but adding it did not fix anything.

What is the best practice for calling nant and nunit from ccnet? Currently I have this setup that I don't like:

ccnet with nant task, and the nant build file uses msbuild and nunit2 tasks to compile and test.

Its hard to find a decent example of ccnet, nant and nunit that really explains the best way to use them all together. I am running ccnet as a service, does that make a difference? I'm trying to keep it as simple as I can, this is roughly what I'm doing:

ccnet.config:

<tasks>
<nant>
<baseDirectory>D:\ccnet\builds\checkout\path</baseDirectory>
<buildFile>go.build</buildFile>
<targetList>
<target>test</target>
</targetList>
</nant>
</tasks>

<publishers>
<merge>
<files>
<file>D:\ccnet\builds\artifacts\path1\nant-results.xml</file>
<file>D:\ccnet\builds\checkout\path\name.dll-results.xml</file>
</files>
</merge>
<xmllogger /> 
</publishers>

And in go.build:

<target name="build" depends="clean">
<msbuild project="name.sln">
</msbuild>
</target>

<target name="test" depends="build">
<nunit2>
<formatter type="Xml" usefile="false" />
<test assemblyname="Tests\path\name.dll" />
</nunit2>
</target>

If I check the build log from the dashboard, then I can see that it does have the xml output from both nant and nunit. But this is not shown on the dashboard itself, why would that be? This is getting to be very frustrating...

I have tried two different types of approach: The auto-magic ccnet approach (just set usefile="false" and let ccnet do its thing). This did not work.

I also tried the manual approach, set usefile="true" and then merge the nant-results.xml and name.dll-results.xml files (no wildcards, just using the exact path to the file which I have triple checked.)

It just does not make any sense at all

Answer 3

Hi JK,

It's a long time since this post, but I've just created an scenario like the one you had and I'm having the same issue. Did you fixed it? How did you finally managed?

Answer 4

Albert - I found the answer by accident some time after asking. It seems that this is ccnet's behavior out of the box. So by default it does not show the compile results in the web dashboard.

You need to locate the file \CruiseControl.NET\webdashboard\dashboard.config and in the buildReportBuildPlugin section, add compile.xsl. It will look like this when added:

<buildPlugins>
  <buildReportBuildPlugin>
    <xslFileNames>
      <xslFile>xsl\header.xsl</xslFile>
      <xslFile>xsl\unittests.xsl</xslFile>
      <xslFile>xsl\modifications.xsl</xslFile>
      <xslFile>xsl\NCoverSummary.xsl</xslFile>

      <xslFile>xsl\compile.xsl</xslFile>

    </xslFileNames>
  </buildReportBuildPlugin>
  <buildLogBuildPlugin />
  <xslReportBuildPlugin description="NCover Report" actionName="NCoverBuildReport" xslFileName="xsl\NCover.xsl"></xslReportBuildPlugin>
</buildPlugins>

The documentation was extremely bad, and I only found this by accident when looking for something else. I was not happy that I wasted so much time when a little documentation or an example on the ccnet site would have solved this in minutes.