NCover integration failure , Not sure how to add artifacts.

Howdy,
 
I am having issues with being able to see my Ncover results in TeamCity. This is because the files Ncover generates does not appear as an artifact under my TeamCity project. I know where it is putting this coverage.zip file on my build agent, is there a way to map this path in order for this to appear as an artifact for my project? Or is this not the way to do the Ncover integration?
 
thanks

http://docs.ncover.com/how-to/continuous-integration/teamcity/

thats what I am following, it talks about teamcity 6.5 but i found what i believe to be equivalent steps in teamcity 7.0

14 comments
Comment actions Permalink

So i think my issue is none of my reports are showing up at all. When i create a new report i am putting my path as

\system\artifacts\Test1\Unit tests\142\.teamcity\.NetCoverage\CoverageReport.xml

above the \system directory is the .buildserver directory. However i assume this doesnt work because the 142 will increase after everybuild. maybe i should try and make the coverage report an archive? How exactly are you supposed to get these Ncover report to display in teamcity?


i think this link is what i should do
http://confluence.jetbrains.net/display/TCD7/Manually+Configuring+Reporting+Coverage

0
Comment actions Permalink

Hi,

You should never place any files under .BuildServer/system/artifacts directly.
If you want a build to produce arifacts, you can define artifacts patterns on the first step of the build configuraiton.

However, you do not need to define any artifacts for TeamCity/NCover integration to work. You can either enable NCover integration in appropriate runner to get the results automatically, or collect coverage in the build script and then use the approach outlines in http://confluence.jetbrains.net/display/TCD7/Manually+Configuring+Reporting+Coverage

If you still have issues doing so, please doublecheck you follow the guide and then post all the steps you make and the results you achieve.

0
Comment actions Permalink

ok I am getting close, I followed those steps and I get this error under the coverage tab

This is an autogenerated index file (there was no index.html found in the generated report).

my index.html file is inside of the coverage.zip file.
the path i pointed out before

.BuildServer\system\artifacts\Test1\Unit tests\144\.teamcity\.NETCoverage\Coverage.zip
.BuildServer\system\artifacts\Test1\Unit tests\145\.teamcity\.NETCoverage\Coverage.zip
.BuildServer\system\artifacts\Test1\Unit tests\146\.teamcity\.NETCoverage\Coverage.zip



Thats where it is putting the coverage.zip file. Note it makes a new directory each time i build my project (i dont mind this).


Importing Coverage Data Files

To pass xml report generated by a coverage tool to TeamCity, in your build script use the following service message:

##teamcity[importData type='dotNetCoverage' tool='<tool name>' path='<path to the results file>']

where tool name can be dotcover, partcover, ncover or ncover3.



I think this is my problem. Where exactly do i put this service message? Do i make a custom script with it?
0
Comment actions Permalink

> I followed those steps and I get this error under the coverage tab

Can you please be more specific on what steps you follow? To my understanding none of the instructions suggests using paths to files under .BuildServer.

Service messages are described at http://confluence.jetbrains.net/display/TCD7/Build+Script+Interaction+with+TeamCity

0
Comment actions Permalink

So here are the steps i followed.

1. I build my project, it builds fine
2. I build my N-unit tests, they also build fine.

that build step looks as following.
Build Step
Runner Type-Nunit
Name- Build Unit Tests
NUnit Runner - 2.6.0
platform - x64
version 4.0
run tests from  - D:\TeamCity\buildAgent\work\368f749b5aad3360\bin\x64\Release\Graphing.*.dll

.Net Coverage
.net Coverage Tool - NCover (3.x)
.net Runtime - .net framework 4.0
bitness - x64
path to Ncover 3- C:\Program Files\NCover
Ncover arguments- //ias .*
NCover Reporting Arguments- FullCoverageReport:Html:{teamcity.report.path}


Should i put the path to the coverage.zip where it says teamcity.report.path?


I also figured out that there are coverage files in this location also D:\TeamCity\buildAgent\temp\buildTmp\coverage9146437422353619597zip\CoverageReport.xml

then they seem to be replicated to the .buildserver directory
as a result i tried adding a build step after this one that runs a .cmd command of
##teamcity[importData type='dotNetCoverage' tool='ncover3' path='D:\TeamCity\buildAgent\temp\buildTmp\coverage9146437422353619597zip\']


Also to spawn or create a service message just add another build step and echo it from a .cmd program correct?

0
Comment actions Permalink

Hi,

If you configured .Net Coverage section in the runner, you should not do anything else.
You should get Coverage tab for the build. If you do not get it, please attach build log.

0
Comment actions Permalink

Hello,

I do get the code coverage tab now but it says
This is an autogenerated index file (there was no index.html found in the generated report).

whats interesting is that i see this

D:\TeamCity\buildAgent\temp\buildTmp\NCover6888334611022129954Report\index.html
the above file just says This is an autogenerated index file (there was no index.html found in the generated report).



Is there a specific location I should make sure the index.html ends up in? To my understanding TeamCity, just expects to find a coverage.zip in a specific location from NUnit?

I believe my error is primarily in the build step where it says NCover Reporting Arguments: i have tried putting // there and I also tried FullCoverageReport:Html:{teamcity.report.path}



the first log (build1.log) i uploaded is where i put // there

the second log (build2.log) i uploaded is where i put // or FullCoverageReport:Html:{teamcity.report.path}  there

the third log (build3.log) is where i put FullCoverageReport:Html:{teamcity.report.path}

Thanks alot for looking at this, I am sure I am just making a trivial mistake.



Attachment(s):
build2.log.zip
build1.log.zip
build3.log.zip
0
Comment actions Permalink

i also saw this

Importing Coverage Data Files

To pass xml report generated by a coverage tool to TeamCity, in your build script use the following service message:

##teamcity[importData type='dotNetCoverage' tool='<tool name>' path='<path to the results file>']





when you say the results file do you mean coverage.xml file?

0
Comment actions Permalink

Also what I found is for the NCover Reporting Arguments in team city.

 

If I put //or FullCoverageReport:Html:{teamcity.report.path}

The only artifact I get is the coverageReport.xml

 

However if I change the NCover Reporting Arguments in team city to just FullCoverageReport:Html:{teamcity.report.path}

*** notice i leave out the //or

Under my artifacts .teamcity/.NETCoverage/ I also have a coverage.zip but the only thing in there is an index.html file that says

“This is an autogenerated index file (there was no index.html found in the generated report).

which one should i be using? neither one is usefull because they both leave have a unusefull code coverage tab?

thanks

0
Comment actions Permalink

So i found a workaround for this problem

It seems as though using many missread the documentation and put in // as the parameter . They also put in FullCoverageReport:Html:{teamcity.report.path}.

In actuality it should be one entire string with the or in there which throws some people off.

//or FullCoverageReport:Html:{teamcity.report.path}

In this scenario (im not 100% sure why), this still didnt work.


I was pleased to find out that

//or Summary:Html:{teamcity.report.path}

Will work. Its not as verbose as the full NCover report but it beats an empty index.html file.

0
Comment actions Permalink

Great work. I can reproduce every single step of your report on TeamCity Enterprise 7.1.2 (build 24170).


But I would not really consider this a workaround for the long run. The summary only consists of a few Top 10s.

I just compared what I find in the buildTmp/Ncoverxxxxx folder in either case (FullCoverageReport and Summary). In the latter case, index.html is simply a copy of summary.html. In the first case, it is this "automatically generated index file" even though a fullcoveragereport.html is part of the folder. So what part of the tool chain is in charge of copying fullcoveragereport.html resp. summary.html to index.html? There seems to be some kind of misconfiguration there.

Since this seems to be an issue for quite a lot of users and since it seems to be around since TeamCity 7.0, I would very much appreciate to see some actions taken by JetBrains. I'm just convincing our management to use TeamCity because of the professional support. Please don't let me down on this one...

0
Comment actions Permalink

Report processor in TeamCity simply checks the numner of .html files under the output folder. If there is only one file, it will be used, otherwise 'autogenerated index' will be used

I improved doc to more explicitly state default and proper NCover parameters


I added more logging to diagnose the problem where //or parameter is misswritten

0
Comment actions Permalink

There are two related issues for this problem
http://youtrack.jetbrains.com/issue/TW-20635
http://youtrack.jetbrains.com/issue/TW-10651

Both issue were fixed for 7.1.3

0
Comment actions Permalink

I'm not sure this is relevant but our NCover arguments get the full coverage report using the following arguments (and they include trending information):

NCover args:

//ias %system.teamcity.build.checkoutDir%\Something.dll
//x coverage.xml
//at \\SomeServer\TrendData\%system.teamcity.projectName%\%system.teamcity.buildConfName%\coverage_trend.trend


NCover Reporting Args:

//or FullCoverageReport:Html:{teamcity.report.path}\index.html
//or Trends:Html:{teamcity.report.path}
//lt \\SomeServer\TeamCity\TrendData\%system.teamcity.projectName%\%system.teamcity.buildConfName%\coverage_trend.trend


The difference being the \index.html at the end of the full coverage report line.  Hope that helps, we are using 6.5.

0

Please sign in to leave a comment.