Coverage file having complete build path in it for files causing issue while merging multiple coverage files together

[nidhipandya030]

Hi Steve,

In our environment we are generating Cobertura coverage files using AltCover on multiple testing servers.

We have dotnet based service which builds on the automation servers having distinct paths and then those services are used by testing servers.

The service for which we are generating the coverage gives the complete path of file where it was build in coverage file. Please find the example of two server's having same file with different path in Cobertura coverage file for the respective servers.

When I am merging this two Cobertura coverage files, the issue is that there are two occurrences for the same file in the merged coverage file.

Source contains two entries for same package when combined. Ex. - ServiceSource\Service\VersionControl\AdapterComponents and others.

For the above stated scenario, is there any solution to get package path for file in-place of a complete build path in coverage file for the service being tested?

Also, if you can suggest a proper way or command to merge Cobertura coverage files is such a way that only one occurrence of file is there in merged file would be helpful.

Thanks!

[SteveGilham]

Getting back to this after other real life issues.

The underlying problem is the lossy cobertura format, which doesn't include any file fingerprint information that would give confidence as to two files of the same file name being the same file, rather than a build for a different platform or version of the code base. It has however recently occurred to me that it would be possible to make a synthetic file path that includes just the fingerprint information, which could be presented as an option instead of the real path.

[SteveGilham]

Apologies for tardiness on may part. Initially I was more concerned about the merging cobertura files, since that wasn't something I provide; and my concerns were that two different build locations could mean completely different source bases, and so not be directly comparable, which led me down a few blind alleys trying to weave that into the reports in a compatible fashion.

Recently I twigged that the actual issue is that I'd simply not grasped the Java idiosyncratic nature of the format (filepath = source root + namespace + classname); and have reworked the conversion to extract the leading common prefix from paths, and use those as <source>s, and then remove such common prefixes from all the filenames.

Pre-release build with this feature/fix attached for validation.

nupkgs.zip

[nidhipandya030]

Hi Steve,

Thank you for sharing the fix for the problem. I appreciate the observations you have provided in the comment.

In our environment currently we have implemented a way in which we are preparing the builds of dotnet based services at a common automation server and then that services is being used by all testing servers, which resolves the issue of coverage generated at testing servers having same file with different paths.

Thank you again!