Changed source paths/filenames in 8.8.173 in combination with reportgenerator

[kimpenhaus]

Good morning @SteveGilham,

sorry bothering you again :) We've noticed a change in the generated cobertura files from 8.8.74 to 8.8.173 in the way the source elements and the filenames are generated.

I don't see an issue in this per se but with our setup the changes break the coverage analysis. we have a multi-project/assembly setup in azure that generats the code coverage with altcover in cobertura format and uses reportgenerator to "transform" this into single file cobertura and sonarqube generic format.

When updating to the latest version we realised that the reportgenerator threw lots of file not found warnings. drilling this down leeds us to the changes done by the new altcover verion. I will try to explain further:

In 8.8.74 it seems thet all filenames were absolute and the sources seem to contain all directories

assembly 1 (sample):

assembly 2 (sample):

With the new 8.8.173 version same sources this seems to have changed in the way that sources contains the lowest common denominator (hopefully you understand what I mean with that :)) dircotryname and the filenames are relative to that:

assembly 1 (sample):

assembly 2 (sample):

the change itself looks conclusive and recduces the size of the generated files - so I don't see an issue here itself.

But when heading to reportgenerator we have the problem that the reportgenerator won't find these files.

What we tried is to set the sourcedirs parameter to /agent/_work/1/s/src but that will only fix those that matches with that directory in the sources. In the given samples /StringExtensions.cs would not be found as the filename is not relative to /agent/_work/1/s/src.

as the assemblies (and maybe future assemblies) might vary in what sources will contain we have no idea what to set in the sourcedirs to cover this in general.

So our question is: Is there a way to have a root source directory which tells altcover to generate all sources and filename relative to that? So that we cann have /agent/_work/1/s/src in altcover and in reportgenerator?

Thanks for any suggestion 🙏🏼

[SteveGilham]

What you report here looks like there's a bug.

This change was intended as a resolution to issue #197, and also to bring the output into conformance with the original cobertura format, based as it is on the Java behaviour of keeping file path and full class name in step with one another.

It should be extracting longest common leading paths - in this case it should be extracting /agent/_work/1/s/src, or at worst /agent directly.

Background:

The class entry in the cobertura source is like

		println("<class name=\"" + classData.getName() + "\" filename=\""
				+ classData.getSourceFileName() + "\" line-rate=\""
				+ classData.getLineCoverageRate() + "\" branch-rate=\""
				+ classData.getBranchCoverageRate() + "\" complexity=\""
				+ complexity.getCCNForClass(classData) + "\"" + ">");

where getSourceFilename() literally composes the path by replacing the separator characters in the class name

	public String getSourceFileName() {
		return this.name.replace('.', '/');
	}

where it is assumed relative to one or other of the source directories.

[kimpenhaus]

Thanks for the quick reply and the insights

It should be extracting longest common leading paths

I guess it does for each assembly independent (if I understood you correctly) but when handling all cobertura files together it does not - not sure if that is even possible?

[SteveGilham]

If this is a case of many assemblies being handled in the one coverage run, aggregation is possible, and it's an oversight on my part (due to only having tested on the single-assembly case) if it doesn't collate across all the assemblies.

Collating multiple independent reports is a whole new requirement.

[kimpenhaus]

I am not pretty sure how one coverage run is defined - but I would assume we only have one run - but I am afraid I am not sure how azure handles this...

our pipeline task is as follows:

      - task: DotNetCoreCLI@2
        displayName: 'run unit tests'
        enabled: True
        inputs:
          command: 'test'
          projects: 'My.Integration.sln'
          arguments: '--nologo --no-build --configuration "$(BuildConfiguration)" /p:CopyLocalLockFileAssemblies=true /p:AltCover=true /p:AltCoverFailFast=true /p:AltCoverAssemblyFilter="^(?!My\.Integration).*$|^(My\.Integration.*?\.Test.*)$" /p:AltCoverAttributeFilter=ExcludeFromCodeCoverage /p:AltCoverFileFilter=\.g\.cs /p:AltCoverCobertura="coverage.cobertura.xml"'

[SteveGilham]

Alas, that's going to be multiple runs, one per test assembly.

I shall double-check what I have anyway, then consider how best to introduce a manually specified common root into the process.

[SteveGilham]

With release v8.9.3, the new /p:AltCoverPackages=[list of source roots with '|' separation between entries] allows you to specify one or more paths that are added to the existing selection of directories directly containing source, to be processed by the same longest leading common sub-tree approach.

For your case, setting /p:AltCoverPackages=/agent/_work/1/s/src should suffice, as that will then become the longest leading common sub-tree.