coverage cache vs multi-module projects

[ivangalkin]

Hi All

I believe there is a severe design problem in the coverage sensors. It is observable if
a) multi-module project is analyzed plus
b) coverage report (e.g. the cobertura one) contains relative paths (see below, <source> is .)

If path is relative, SensorContext::fileSystem().baseDir().getAbsolutePath() is used as a base directory while parsing. After report is parsed the corresponding CoverageMeasures structure is cached. For the next sub-project the base directory should be actually recalculated, but it isn't.

I believe the cache can be used only if all paths are absolute. This design idea applicable to all sensors. If we don't check/force this fact, it's not safe to cache any reports (and we had a similar discussion in #1423).

The correct solution in my opinion should be

a. Terminate if coverage report of a if multi-module project contains relative paths and/or
b. Provide a property in order disable the cache

I know, that the coverage output can be customized, but the current implementation is a pitfall and must be fixed or at least documented IMHO.

<coverage ... version="gcovr 3.4">
  <sources><source>.</source></sources>
  <packages>
     <package>
        <classes><class filename="relativePath"> ... <class/>
        </classes>
    </package>
 </packages>
</coverage>

Best regards,

[guwirth]

Hi @ivangalkin, instead of fixing the sensor I think it's the better way to use the generic test and coverage sensors in future: https://docs.sonarqube.org/display/SONAR/Generic+Test+Data. In our plugin we can provide a transformation mechanism and the XLST.