Sonar bugs when there is no differences in code


We use SonarCloud with Gitlab and Jenkins. The code source is in C++.

Today, the developers are allowed to push commits on master/main/develop branches (I know, it is a devilish config…).
When a developer asks for a merge request on Gitlab, the IC runs several steps on the source branch, among which Sonar.
If all these steps are successful, the scripts tries to merge (git --no-commit), but as each commit on master/main/develop must be checked (because of the devildish politic), the IC workflow is run again.

If there isn’t any commit on the target branch since the the fork point (a “fast forward” could be applied), Sonar doesn’t see any difference, and the file build-wrapper-dump.json is empty.
To be exact, here what it contains :


and I guess that Sonar doesn’t like that at all.

Here is what I get in the log :

15:51:50  [2024-02-28T14:51:50.362Z] INFO: SonarScanner
15:51:50  [2024-02-28T14:51:50.362Z] INFO: Java 17.0.6 Eclipse Adoptium (64-bit)
15:51:50  [2024-02-28T14:51:50.362Z] INFO: Windows Server 2019 10.0 amd64
15:52:02  [2024-02-28T14:52:02.429Z] INFO: ------------------------------------------------------------------------
15:52:02  [2024-02-28T14:52:02.429Z] INFO: EXECUTION FAILURE
15:52:02  [2024-02-28T14:52:02.429Z] INFO: ------------------------------------------------------------------------
15:52:02  [2024-02-28T14:52:02.429Z] INFO: Total time: 12.116s
15:52:02  [2024-02-28T14:52:02.429Z] INFO: Final Memory: 15M/80M
15:52:02  [2024-02-28T14:52:02.429Z] INFO: ------------------------------------------------------------------------
15:52:02  [2024-02-28T14:52:02.697Z] powershell.exe : ERROR: Error during SonarScanner execution
15:52:02  [2024-02-28T14:52:02.697Z] At C:\somaPath\someProject@tmp\durable-fb8a5acb\powershellWrapper.ps1:3 char:1
15:52:02  [2024-02-28T14:52:02.697Z] + & powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -Comm ...
15:52:02  [2024-02-28T14:52:02.697Z] + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
15:52:02  [2024-02-28T14:52:02.697Z]     + CategoryInfo          : NotSpecified: (ERROR: Error du...anner execution:String) [], RemoteException
15:52:02  [2024-02-28T14:52:02.697Z]     + FullyQualifiedErrorId : NativeCommandError
15:52:02  [2024-02-28T14:52:02.697Z]  
15:52:02  [2024-02-28T14:52:02.697Z] java.lang.IllegalStateException: The "build-wrapper-dump.json" file was found empty. Please make sure that:
15:52:02  [2024-02-28T14:52:02.697Z]   * you are using the latest version of the build-wrapper and the CFamily analyzer
15:52:02  [2024-02-28T14:52:02.697Z]   * your compiler is supported
15:52:02  [2024-02-28T14:52:02.697Z]   * you are wrapping your build correctly
15:52:02  [2024-02-28T14:52:02.697Z]   * you are wrapping a full/clean build

If I add any commit in the target branch, it does work.


Does your pipeline do a full clean build with each run? The build-wrapper can only pick up what was actually built in the run.


Not, it doesn’t, but it can if we ask for in the build settings.

And in this case, that does work, because then, there is a difference between the branch to merge and the master. But we don’t want to do a full clean each time.


If it’s not built, it won’t be analyzed.


Why do you mean by “built” ? Compiled/linked ?




That’s OK for me if it doesn’t do any analysis.
But I don’t think Sonar has a good behavior when this case occurs.
It should in my opinion just states it doesn’t have anything to do, and not crashing.


We have a fail-fast philosophy. If you’re not going to get an analysis, we figure you should know that immediately, rather than only finding out after you happen to notice that your project has 0 issues, wondering why, and investigating.


I agree that philosophy. But for me, it shouldn’t be an error, but a log, and an OK status.
When I do git pull when there isn’t any update, git just tells me that I am up to date. It doesn’t crash.


Because there’s no information loss.

But each analysis replaces the last.

  • If your first analysis - with a full build - finds 100 issues
  • And then your second analysis - with nothing built and therefore nothing analyzed - finds 0 issues

That represents a data loss. That’s not benign.


I understand your point of view, but we’re not in this case.
As wrotten in the inital post, the previous analysis was OK. So Sonar should do the following inference :

(previous_analysis == OK) && (no_change) => (current_analysis == OK)

Also, I should be able to change a Markdown file on a branch (so there won’t be any new built) without having to do a full clean.

Also :

The problem is that the error in the log isn’t clear at all, and we had to wonder why and investigate about the problem.


That’s on your CI to do. You tell SonarScanner to run and it’s going to run.

Fair point. I’ll refer that internally.


Hi @Oodini, and thanks for sharing the problem with us,

One thing to mention here: If the analysis is simply “skipped”, and results are reported back as if no issues were detected, then this can break issue tracking on the server. The analyzer has to do a full analysis on each version, and detected issues have to be reported to the server in order for issue tracking to work.

We already do a similar inference when the analysis cache is enabled. In this case, the analyzer can reliably ensure that no change is detected, efficiently report the issues unchanged, and end with a successful current_analysis. As a plus, the analysis cache is able to perform this optimization on a more fine-grained level, skipping analysis of individual translation units when possible.

I can understand the wish to avoid a full clean build after each change, and I think that there are a few ways to achieve that:

  1. Use a compilation database to configure the analysis instead of wrapping a clean build (if supported by your build system).
  2. It is also possible to use something like ccache to speed up the clean build: build-wrapper has to wrap a full build in order to log all needed compilation commands into the generated build-wrapper-dump.json, but ccache can reuse build artifacts and save time when no changes are detected in the translation unit being compiled.
  3. Use Automatic Analysis for C++ and you don’t even need to invoke the scanner in your CI.

I hope this helps.

Best regards,