rafaelsilvaaaaa10 opened a new issue, #8648: URL: https://github.com/apache/incubator-devlake/issues/8648
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/incubator-devlake/issues?q=is%3Aissue) 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? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
