Giters

danielpalme / ReportGenerator

ReportGenerator converts coverage reports generated by coverlet, OpenCover, dotCover, Visual Studio, NCover, Cobertura, JaCoCo, Clover, gcov or lcov into human readable reports in various formats.

Home Page:https://reportgenerator.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Sonarqube format clashes with DeterministicSourcePaths=true

JustusGreiberORGADATA opened this issue · comments

commented

Hi,

when you have a test coverage report with DeterministicSourcePaths=true, paths will start with /_/ to indicate the source root of the compilation. When you convert a report like this to the Sonarqube format, it will use the same paths. These paths sadly don't satisfy the requirements of the format, which include the following for the path:

Its path attribute can be either absolute or relative to the project's base directory (root module).

https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/test-coverage/generic-test-data/

Now I am not sure if this tool should be responsible for modifying the paths. I could totally understand if this is out of scope. On the other hand I could also understand if handling paths like this is out of scope for the "Sonarqube Generic test coverage report format" itself, considering that it's supposed to be generic. So I wanted to open this issue as a discussion about whether normalizing the paths for the coverage format is something this tool should do or not.

commented

I just realized that GitHub also has the discussion feature and it is enabled on this repository. If this better fits there, maybe someone could move this issue, to a discussion.

commented

In your case you can use a little Powershell script to set the correct the path information. This might look like the following example:

(gc "coverage.xml") | % { $_ -replace "/_/", "/real/path/" } | Out-File "coverage.xml" -Encoding UTF8

ReportGenerator can't guess the correct path in that case.

commented

ReportGenerator can't guess the correct path in that case.

Interesting, I thought ReportGenerator in some cases already does try to determine the right paths here:

https://github.com/danielpalme/ReportGenerator/blob/main/src/ReportGenerator.Core/Parser/FileReading/LocalFileReader.cs#L106-L168

That's why I thought maybe it could, for example, emit absolute paths and be spec-compliant that way. As I said, though, I am totally fine with this being out of scope.

commented

Interesting, I thought ReportGenerator in some cases already does try to determine the right paths here:

https://github.com/danielpalme/ReportGenerator/blob/main/src/ReportGenerator.Core/Parser/FileReading/LocalFileReader.cs#L106-L168

Correct. But this only works (automatically) if you are using Azure DevOps or Github Actions.

Another option would be to supply a directory manually via the -sourcedirs:.... command line parameter.
Maybe that worth a try for you.

commented

Another option would be to supply a directory manually via the -sourcedirs:.... command line parameter. Maybe that worth a try for you.

Thanks, unfortunately I already tried providing the command line parameter before writing this issue and noticed that it does not cause ReportGenerator to actually change the paths, when converting a report to the Sonarqube format. As far as I understand, it is only used to load the files for some other tasks.

I just thought this tool supporting something like -sourcedirs:... -convertPathsToAbsolute for converting a report might be something that's worth implementing, considering the SonarQube format does not support the deterministic path style.

(And then maybe defaulting to true for that option if the format is SonarQube, since it seems like a sane default.)

Anyway, I will try the manual replacement; that should work too. Thanks for the suggestion.