[Bug][SonarQube Plugin] Coverage metric mismatch between SonarQube API and DevLake dashboards

[rafaelsilvaaaaa10]

Search before asking

• I had searched in the issues and found no similar issues.

What happened

We identified a mismatch between code coverage metrics reported by SonarQube and the values stored and displayed via Apache DevLake dashboards.

For example, for the project my-api-xpto, SonarQube returns the following via API:

coverage = 95.3%
line_coverage = 97.3%
lines_to_cover = 445
uncovered_lines = 12
conditions_to_cover = 113
uncovered_conditions = 14

However, DevLake stores and displays a different value for "coverage", always matching line_coverage instead of SonarQube’s combined coverage formula, which includes condition coverage.

SQL query in the DevLake database (cq_file_metrics) confirms the behavior:

coverage = (lines_to_cover - uncovered_lines) / lines_to_cover * 100
--> 97.3%

This means DevLake is not using the same formula as SonarQube, which is:
coverage = (CT + LC) / (B + EL)

As a result, DevLake dashboards show a higher coverage percentage than the real value reported by SonarQube.
The discrepancy affects all projects integrated with the SonarQube plugin.
I only noticed this difference after performing a detailed validation of coverage values.

What do you expect to happen

DevLake should calculate the “coverage” metric in a way that matches SonarQube’s official API metrics, including:

• uncovered_conditions
• conditions_to_cover
• full SonarQube combined-coverage formula (CT + LC) / (B + EL)

Or, at minimum, DevLake should clearly distinguish between:

• line_coverage
• coverage (combined coverage)

so dashboards do not display misleading values.

How to reproduce

1. Configure the DevLake SonarQube plugin and run ingestion for any project.
2. Query SonarQube API:

GET /api/measures/component?component=my-api-xpto&metricKeys=coverage,line_coverage,lines_to_cover,uncovered_lines,conditions_to_cover,uncovered_conditions

3. Compare with DevLake database:

SELECT lines_to_cover, uncovered_lines, coverage
FROM cq_file_metrics
WHERE project_key = 'sonarqube:SonarqubeProject:6:my-api-xpto';

4. DevLake always computes:

coverage = line_coverage

instead of the SonarQube combined coverage formula.

5. Grafana dashboards connected to DevLake will display the wrong “coverage” value.
6. The issue happens for all SonarQube projects.

Anything else

1. The problem occurs 100% of the time for all projects.
2. Raw file-level data in DevLake is correct.
3. Only the aggregated coverage calculation diverges from SonarQube’s official formula.
4. This impacts our governance dashboards and executive reporting.

Version

Apache DevLake version: v1.0.3-beta8@cfe519c SonarQube version: v25.11.0.114957 (Community Build)

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[dosubot]

Hi @rafaelsilvaaaaa10! I'm Dosu and I’m helping the incubator-devlake team.

You're correct—DevLake's SonarQube plugin currently stores the coverage metric exactly as provided by the SonarQube API, without recalculating or combining it with condition coverage. The mapping logic simply parses the "coverage" value from SonarQube and assigns it to DevLake's internal model, so the displayed coverage in dashboards matches whatever SonarQube returns for that field, which is often just line coverage and not the combined formula (source), (source).

There is no code or documentation in DevLake that distinguishes between "line_coverage" and "coverage" or explains the calculation method. To align DevLake with SonarQube's combined coverage formula, you would need to update the plugin to ingest both line and condition coverage metrics, store them separately, and either calculate the combined coverage in DevLake or display both metrics distinctly in dashboards.

If you're planning a PR, focus on updating the ingestion logic to fetch all relevant coverage metrics (including conditions), modify the data model to store them, and adjust dashboard queries to either use the combined formula or show both metrics side-by-side. Let me know if you want a more detailed breakdown of the code changes needed!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[robertofalzoni]

Would be good to have some project level metrics into cq_projects table for example.