Cobertura report with absolute path for all files

Describe your environment

• Version of OpenCppCoverage: 0.9.7.0
• Architecture (x86/ x64): x64
• Windows version: Windows 10

Describe your problem

Steps to reproduce:

1. Run open cppcoverage with cobertura report
2. Even though if I run OpenCppCoverage from an specific folder, it always references the files from the root (C:). This makes the report incompatible with SonarQube which expects the path to be found from a base dir. Would be interesting if we could specify this basedir or use the dir that OpenCppCoverage executed to make the report easier to integrate with other tools.

Attached file

<packages> <package name="C:\SandBox\UnitTestFrameworkEvaluation\Debug\ExampleCode.MSTests.dll" line-rate="0.97560975609756095" branch-rate="0" complexity="0"> <classes> <class name="user.cpp" filename="sandbox\unittestframeworkevaluation\examplecode\user.cpp" line-rate="1" branch-rate="0" complexity="0"> <methods/>

Hello,

I need to check if there were any changes to the Cobertura format. The current format works well with Jenkins and Team Foundation Server.

Can you provide a full Cobertura coverage file that works with SonarQube? Which plugin are you using?

OpenCppCoverage

Hi,

I'm using the sonar.cxx plugin, which is the community one. I did this little project to "fix" the report file (just the base path) and it is working fine.

I guess the problem is with the files having the root directory:

https://github.com/ericlemes/CoberturaCoverageReportBaseDirFixer

I hope that helps. Thanks for the prompt answers.

Eric

Hello,

Thanks a lot for the fix! I will integrate it in the next release.

OpenCppCoverage

Hi!

My pleasure. Thanks for the great tool. If you can ping me when the release is done, I can do some tests.

Regards,

Eric

Hi @OpenCppCoverage !

I have to manually trim paths for codecov.io, otherwise the cobertura reports will create non-existent references. For example, from the repo root I have a file include/filesystem/path.hpp. From AppVeyor using OpenCppCoverage.exe and a --export_type cobertura:coverage.xml, the paths will cause problems. On AppVeyor, I get cloned to C:\projects\filesystem, the C:\ is encoded at the top of coverage.xml, and remaining paths include projects\filesystem (as mentioned in other places, this is coming from the .pdb file).

This means that I now have coverage reported for include/filesystem/path.hpp (correct, from Travis), and projects/filesystem/include/filesystem/path.hpp (incorrect, from vanilla coverage.xml on AppVeyor). In my .appveyor.yml script I use the following "sed-like" filter:

- ps: (Get-Content .\coverage.xml) -replace '(.*)filename=\"projects\\filesystem\\(.*)\"(.*)', '$1 filename="$2"$3' | Set-Content .\coverage.xml

I think a very simple --cobertura_trim "C:\projects\filesystem" command-line option for non-Jenkins people would be really useful / helpful (especially in conjunction with CMake // add_custom_command and ${CMAKE_CURRENT_SOURCE_DIR}!). Note that the C:\ can still be safely included (at least for codecov.io):

  <sources>
    <source>c:</source>
  </sources>
  ...
    <class name="path.hpp" filename="include\filesystem\path.hpp" line-rate="0.75" branch-rate="0" complexity="0">

since I'm pretty sure codecov.io is not using <sources> at all.

If you do not intend to enable a specific cobertura path stripping option, but think my (terrible) PowerShell script is worthy of documenting officially, please let me know where in docs you think it could fit and I will PR or edit the wiki!

The primary reason for posting this was to hopefully explain with precision how absolute paths here can cause problems, but also provide a solution for other readers using the regex-replace Get-Content ... Set-Content pattern shown above.

Thank you very much for OpenCppCoverage, I am thrilled to be able to report coverage statistics on my Windows-specific code :heart:

Hi @svenevs,

I think this will help: https://github.com/ericlemes/CoberturaCoverageReportBaseDirFixer

This is how I've fixed for SonarQube. Not elegant at all, but does the trick.

Cheers

Eric

Hi @OpenCppCoverage ,

Are there already plans for a new release which will contain a fix? If it's close to be released we may not need to fix the xml manually to get it running with SonarQube..

Thanks a lot.

@orgi : There is now a SonarQube plugin.

I am having a similar issue. I'm running the SonarQube plugin for OpenCppCoverage to generate a code coverage report for SonarQube Enterprise. The report has the proper format needed by SonarQube; however, SonarQube requires the path attributes in the XML file to match the exact source file paths as seen by the SonarQube build-wrapper.

I am building C++ projects in Visual Studio 2019. I have SonarQube's build-wrapper building my project via MSBuild. The source files in this vcxproj project are located in a relative path. When the build runs, MSBuild (or the SonarQube build-wrapper) show source file paths such as

D:/work/Dev/Windows/CollectorUtils/CollectorUtils/../../../AllPlatforms/CollectorUtils/FileUtils.cpp

but the paths in the XML report generated by the SonarQube plugin for OpenCppCoverage show the same source file listed as:

d:\work\dev\allplatforms\collectorutils\fileutils.cpp

In order for SonarQube to ingest this XML report, I have to manually modify the paths. I was unable to modify this path using OpenCppCoverage's --substitute_pdb_source_path parameter.

It would be great if OpenCppCoverage had a command line parameter to alter the source file paths within a report. In my case:

--modify-path d:\work\dev\allplatforms\collectorutils\?D:/work/Dev/Windows/CollectorUtils/CollectorUtils/../../../AllPlatforms/CollectorUtils/

The above uses the search-and-replace syntax of --substitute_pdb_source_path.

Even the above proposed enhancement would be insufficient, because SonarQube must see each source file in the XML report as having the same letter case as what the SonarQube build-wrapper sees. fileutils.cpp would not match FileUtils.cpp, and the source file would be excluded. Perhaps several new options would be needed:

--source_path_relative --source_path_base_dir D:/work/Dev/Windows/CollectorUtils/CollectorUtils --source_path_preserve_case --source_path_path_sep /

This issue is caused by some simple coding mistake, maybe.

1. The input for a content of source element may be wrong. https://github.com/OpenCppCoverage/OpenCppCoverage/blob/71c622215f18d76aeabe35c45440b744f7c55ca8/Exporter/CoberturaExporter.cpp#L100-L104 std::filesystem::path::root_name() returns the root directory of filesystm(like C:). This behavior is probably not what you expected. I Expect, an input for a content of source element is one of the --sources directories.
2. The input for a content of filename attribute may be wrong.
   https://github.com/OpenCppCoverage/OpenCppCoverage/blob/71c622215f18d76aeabe35c45440b744f7c55ca8/Exporter/CoberturaExporter.cpp#L76 std::filesystem::path::relative_path() returns the relative path from the root directory. This behavior is probably not what you expected. I Expect, an input for a content of filename attribute is the relative path from one of the --sources directories.

I think, you can easily fix it.

Hi @OpenCppCoverage, thank you for your very helpful tool! :) It seems that Gitlab requires the same format as described in this thread to recognize the files correctly. So as @berryzplus wrote it would be very cool if in sources there could be a root directory from the --sources parameter and in filename there would be a relative path from that root directory. Alternatively it would be very helpful to be able to define a root directory as described in the first post. Thanks again!