cobertura coverage does not support drive letter only in source tag

[shader-man]

Hi,

generating a cobertura report from opencppcoverage fill all the "filename" paths in lowercase ( info extracted from PDB files on windows )

<?xml version="1.0" encoding="utf-8"?> <coverage line-rate="0.34319526627218933" branch-rate="0" complexity="0" branches-covered="0" branches-valid="0" timestamp="0" lines-covered="116" lines-valid="338" version="0"> <sources> <source>f:</source> </sources> <packages> <package name="f:/build/MyDLL.dll" line-rate="0.34319526627218933" branch-rate="0" complexity="0"> <classes> <class name="file.h" filename="f:/my/file/path/file.h" line-rate="0" branch-rate="0" complexity="0">`

the cobertura coverage sensor cannot associate the file path in mixed case with this windows lower case path and gives the following error :
07:44:03.310 INFO: Added coverage report 'f:/My/File/Path/report.xml' (parsed by: CoberturaParser) 07:44:03.311 DEBUG: save coverage measure for file: 'f:/my/file/path/file.h' cxxFile = 'null' 07:44:03.311 DEBUG: Cannot find the file 'f:/my/file/path/file.h', ignoring coverage measures

I fed a case-correct cobertura to the plugin and it worked.

would it be possible to ignore the casing for file association?

thanks,

[guwirth]

Hi @shader-man,

which version of the plugin are you using? There was a similar issue we fixed with 1.2.2 snapshot (#1678, #1679). You can download it from here: https://ci.appveyor.com/project/SonarOpenCommunity/sonar-cxx/branch/master/artifacts

Regards,

[shader-man]

Hi @guwirth ,
My bad, I'm using the 1.2.1-SNAPSHOT version, i will try the 1.22 and let you know.
Thanks

[shader-man]

Hi @guwirth ,
i have the version C++ (Community) 1.2.2.1653 installed and running but it stil can't find my files

07:44:03.310 INFO: Added coverage report 'f:/My/File/Path/report.xml' (parsed by: CoberturaParser) 07:44:03.311 DEBUG: save coverage measure for file: 'f:my/file/path/file.h' cxxFile = 'null' 07:44:03.311 DEBUG: Cannot find the file 'f:my/file/path/file.h', ignoring coverage measures

I don't know if the problem is still because of the lowercase or because i'm missing a / between my drive letter and the root folder.
in my opencppcoverage generated cobertura xml , file i have the following :
.... <sources> <source>f:</source> </sources> ... <class name="file.h" filename="my/file/path/file.h" line-rate="0" branch-rate="0" complexity="0"> ...
should there be a / inserted somewhere ? in < source > or < filename > ?
thanks

[amai2012]

@shader-man Did you forget to re-open this issue?

For me plugin 2.0.5 still shows the same problem.
But probably the best fix would be adressing this in OpenCppCoverage/OpenCppCoverage#53

[guwirth]

Hi @shader-man,

hearing nothing means always it works :-).

I don't know if the problem is still because of the lowercase or because i'm missing a / between my drive letter and the root folder.

There must be a / after the drive name f:my/file/path/file.h.

This is the parser reading Cobertura coverage files:
https://github.com/SonarOpenCommunity/sonar-cxx/blob/master/cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/cobertura/CoberturaParser.java

These are the unit tests:
https://github.com/SonarOpenCommunity/sonar-cxx/blob/master/cxx-sensors/src/test/java/org/sonar/cxx/sensors/coverage/CxxCoberturaSensorTest.java

Here are test cases we are using:
https://github.com/SonarOpenCommunity/sonar-cxx/tree/master/cxx-sensors/src/test/resources/org/sonar/cxx/sensors/reports-project/coverage-reports/cobertura

Maybe you can have a look and provide a test file for your case.

Regards,

[guwirth]

Hi @shader-man,

don't know if the sample is still valid?

<sources>
   <source>f:</source>
</sources> ... 
<class name="file.h" filename="my/file/path/file.h" line-rate="0" branch-rate="0" complexity="0">
... 

<source>f:/</source> should work?

Problem seems to be here:

sonar-cxx/cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/cobertura/CoberturaParser.java

Line 79 in f267915

var result = path1.resolve(path2).normalize();

Regards,

[shader-man]

Hi @guwirth , sorry i can't remember what was happening 3 years ago :) . I think we went around this issue by having a python script fixing the path in the problematic reports.