Humm, indeed the results are inconsistent. SonarQube should report 47.6%, without any doubt
The first thing I am thinking about is a corrupted Elastic Search index. The way to verify that would be to regenerate the index, but that’s a rather impactful procedure on large platforms:
- Stop SonarQube
- Wipe the index in
<SONARQUBE_HOME>/data/es7 (or es6 depending on your version)
- Restart SonarQube
- Wait for the index to be rebuilt
I doubt of any other option but there ways to narrow down the problem to the module/dir/file where the problem happens.
You can recursively check at the coverage level for each subcomponent of the problem and recursively down up to files, to hopefully find that all but one or a few components have OK coverage.
Looking at the nature of the subcomponent where the coverage is inconsistent can help understanding what’s special that would break coverage calculation.
Checking recursively is not convenient from the UI but you can do that fairly easily with the APIs:
returns the coverage data of all the subcomponents/subdirs of the project, along with the subcomponent key
You check the values, and recurse on subcomponents whose 3 metrics are not consistent to hopefully narrow down the culprit (with another call to