NewCode missing issues for Projects with git submodules

We have some fairly complex c/c++ projects (100.000 lines of code and more) based on git and having multiple git submodules and sometimes also submodules of submodules. We noticed that at least sometimes NewCode QG (relative to master branch) does not show properly new issues popping in new branches. Here is a concrete example.

Looking at the branch NewCode QG overview page it says everything is clean:

Comparing branches QG overall code page and master overall code page look also pretty the same on the first look:

But if one examines maintainability issues closely you can see that branch actually has seven new ones not recognized by NewCode!

Our observations and guesses so far:

  • It seems to be related to git submodules, seems only to happen for files from submodules
  • We could observe this behaviour over a wide range of sonar versions (most 10.x versions, maybe even in 9.X (unsure, but seems likely) and 2025.1 which is the latest we have used so far
  • So far only firmly confirmed for “low level code smells” or maintainability issue as they are called since the clean code redesign
  • Only confirmed so far for c/c++ projects

Also note that we have and had other issues with git submodules which might or might not be related.

For a long time we needed to add the option sonar.scm.exclusions.disabled = true to the scanner, otherwise code inside submodules were ignored completly by analysis, see also:

But this seems to be fixed now as having this option added or not seems not make any difference for analysis results.

A still ongoing issue we have with submodules is that we get a bunch of warnings that sonar cannot handle blame information for all source files properly:

Which in itself would not be that bad for us, except it is somehow influential for this new-code issue here.

As we managed to create a controlled example situation just for debugging where the not recognized new issues are all in one dummy file and we did have the scanner running with debug output we also scanned the output of the scanner for any noteworthy output concerning this file, but did not really find anything, except maybe that this file is also one of the files where sonar cannot handle blame for:

WARN Missing blame information for the following files:
WARN * Runtime/lib/ipc/services/mqtt/ipc_mqtt_callee.cpp
[…]
WARN * Runtime/lib/googletest/googletest/test/googletest-throw-on-failure-test_.cc
WARN * icl/sonar_issues.cpp
[…]

System Setup:

Hey @morco

Thanks for the report.

This is a known issue that (was) tracked at GFB-6. It was closed for inactivity, but I’ll ping the team to see if we should reopen it.

1 Like

So, is there anything happening here? As I already said, not having blame is obviously not ideal but liveable. But having new Issues in submodules not detected as NEW is obviously a big issue, especially with the whole clean code redesigning on your behalf which heavily focus on (relative) new code.

Hello @morco ,

As @Colin pointed out, this issue was tracked long ago but it was closed. Let me check with our product team to know if this becomes a priority again o not.

Cheers,
Javier

I am having the same issue with Enterprise Edition v2025.5 (113872) on a C++ codebase using git and gitlab. We recently reorganized our project to a git repo of submodules and the scan log shows all files from submodules are missing blame information. I tried enabling “Disable the SCM Sensor” to see if that would fallback to a method that does not require git blame information, and it seemed to work at first, but identifying new code now only works intermittently.

We can prove issues are being found in a branch by manually navigating to files from the “Code” tab, but “New Code” still shows 0 issues. We also noticed that after merging a feature branch the issues show up in our develop branch, which is set to identify new code as changed within 30 days. Finally, we tried setting the whole project to use a new code setting of 30 days, but then in branches the new code tab is empty and says a second analysis is needed.

This is a big deal for us as SonarQube loses most of its benefit if it is not helping developers identify issues in their feature branches.

Hi @rngoodn ,

Thank you for your message. I am sorry this topic is generating such a friction for your organization.

We will take a closer look at this topic again.

Best,

Joan

1 Like

Any updates on this?