We discovered a very strange behaviour with how SonarQube Server, regardeless of the edition and version, is resolving LCOV relative file paths: it is actually relsolving them from the sources directory instead of the LCOV file one.
Typically, with sonar.src set to src and LCOV file being coverage/lcov.info, ../src/foo/bar.ts is resolved to foo/bar.ts instead of src/foo/bar.ts.
This is a violation of LCOV specification, but what I found strange is the fact that, regardless of the important amount of threads opened about this subject in the last years, the problem was never fixed.
And then I stumbled upon this test:
If I read it correctly, it asserts that the paths are resolved from the sources directory, instead of the LCOV report path.
Which means that it is not a bug, but a conscious decision from Sonar, made 6 years ago.
I may be wrong, I may be misreading the test. But if I’m not wrong, can you please share why you made such a decision, that violates the LCOV specification?
And, isn’t this decision now making impossible to actually fix the problem? I mean, how many projects have now deliberately post-processed their LCOV files so that Sonar understands it, and how many of them would start to lose coverage if the problem is fixed?