SonarQube code coverage includes files not in compile_commands.json

SonarQube Server / Community Build
1

We are using the following setup, which is getting updated soon:

  • SonarQube Server - Developer Edition v2025.2 (105476)
  • build-wrapper-linux-x86-64 v6.65 - from our sonarqube instance
  • SonarScanner CLI 7.2.0.5079
  • C and Gcov for analysis

We have a monorepo with several possible builds, each in a separate SonarQube project. There is one generic sonar-project.properties file and we want to avoid manually maintaining one for each target.

According to the documentation (and my understanding of it :grinning_face: ), we can rely on the build wrapper output to analyze only what is included in our build.

Any file that doesn’t end up in a compiled compilation unit will not be analyzed. As a consequence, source files that are not compiled and header files that are not included in any compiled source file will not be analyzed.

from Prerequisites | SonarQube Server 2025.2 | Sonar Documentation

However, some files that aren’t in the build wrapper output will show up in the code coverage analysis, most likely since they have a gcov output file due to having or being used in unit tests for other targets.

Does this mean that “compiled compilation unit” isn’t limited to the output from the build-wrapper, but also includes any gcov output?

Is there a setting that will exclude gcov output in this case?

I went through the monorepo documentation in Enterprise edition and couldn’t see something that would work around this issue.

I also went through the release notes from v2025.2 to v2026.3, but couldn’t find anything relevant, so our server version shouldn’t matter, correct?

2

Hello Edoardo,

Welcome to the community!

To clarify how SonarQube handles your files, here is a breakdown of how scoping works:

  • Global Analysis Scope: The scope of any analysis is primarily set by the global sonar.sources property. Any source file that matches this filter will be taken into account (see Analysis Scope Parameters).

  • Implicit Scope Tuning for C++: For accurate analysis of C++ code, the compilation commands are required, which are provided via the compile_commands.json file. Since the compile command is needed to analyze a file, the contents of this JSON file introduce an implicit scope tuning: only files that are in the sonar.sources scope and also in compile_commands.json will be analyzed (see Understanding C-Family Analysis).

  • Coverage Reports: SonarQube does not generate the coverage report itself, but relies on importing it from external tools (such as gcov in this case). The scope for this coverage is also set by sonar.sources. This is disconnected from which files actually end up being analyzed due to the implicit scope reduction from the compile commands.

If you want to define strict limits on the files included in each SonarQube project, configuring an accurate sonar.sources property is your best course of action.

Alternatively, you could ensure your gcov reports are generated specifically for that build, though I suspect you are already doing this. Is then the issue that certain files that were not analyzed because they were not in compile commands, are showing up as “uncovered”?

Regards,