Incomplete analysis with sonarqube on some new branches on project

Hi ,


  • SonarQube 9.0 dev edition
  • analysis triggered from push on git with pipeline jenkins +gitlabhooks
  • analysis run by maven
  • quality gate activated
  • new code managed by “new version” mode
  • language java

We had some protected branches master, dev and maintenances. We use quality gate to block merge request on these protected branch.

But we have sometimes a non rationnal behavior.
For example, a dev want to fix some bug on a maintenance version 1.2.0 . He will create a working branch from maintenance-1.2, the ci/cd will triggered a sonar analysis and the whole issues founded will be 10 on legacy code.
When it will trigger again the analysis with only a change in a properties files, sometimes new issues appear on legacy code:

  • new issues are on legacy code with no changes
  • new issues are on files already with other issues
  • two branches with same code run the same hour , give two different result
  • no change on the sonar profil

The status is :

  • maintenance-1.2 : 10 issues on overall code before and 10 after the merge with working_branch
  • working branch : 10 issues first analysis, 20 in second analysis on overallcode
  • copy-maintenance-1.2 : 20 issues on overall code
  • copy-working_branch : 20 issues on overall code

The only thing suspicous we found, it was some encoding warning in logs.
Do we have some caching ?
What we want to understand, it’s how we can have the new issues on the legacy code without change on theses files and with older analysis on them.

We have tracking the problem last days, and have more informations.

We have project which detect 1448 code smell on overall code or 1263:

  • 1448 when the version doesn’t change in the push scope
  • 1263 when the version change in the push scope

The good number is 1448 and concerning only old code legacy. The impact is every time the team change the revision, they will have a quality gate to fail.

The impact is the next push with no version, will have a quality gate at fail due to the issue not detected in the prebious push with the version change

Someone have encountered this case?


What is your New Code Period setting?

Also, thanks for providing that graph. The dip & return to the former level is suspicious. Typically that indicates a fluctuation in what’s being analyzed. Can you examine your analysis logs to see if they give any indication of that?



We are on “previous version” mode for the “New Code”.
About the logs, do you mean shell logs when running the maven command or another logs through the ui of sonar server ?

On sonar logs through maven, but on aother branch :

  • see a difference around a warn log about encoding
  • see a difference near UCFGs ( below see extract with older logs, another branch same problem)

analysis with less issue

[INFO] Read 1450 type definitions
[INFO] Reading UCFGs from: /var/docker_env/workspace/12584/target/sonar/ucfg2/java
[INFO] 12:06:54.859138 Building Runtime Type propagation graph
[INFO] 12:06:54.978653 Running Tarjan on 13506 nodes
[INFO] 12:06:55.008002 Tarjan found 13428 components
[INFO] 12:06:55.055075 Variable type analysis: done
[INFO] 12:06:55.06033 Building Runtime Type propagation graph
[INFO] 12:06:55.221852 Running Tarjan on 13494 nodes
[INFO] 12:06:55.235888 Tarjan found 13418 components
[INFO] 12:06:55.274921 Variable type analysis: done
[INFO] Analyzing 3517 ucfgs to detect vulnerabilities.

analysis with more issue

[INFO] Read 1562 type definitions
[INFO] Reading UCFGs from: /var/docker_env/workspace/12585/target/sonar/ucfg2/java
[INFO] 14:47:09.800576 Building Runtime Type propagation graph
[INFO] 14:47:10.002187 Running Tarjan on 27387 nodes
[INFO] 14:47:10.059744 Tarjan found 27284 components
[INFO] 14:47:10.19646 Variable type analysis: done
[INFO] 14:47:10.201984 Building Runtime Type propagation graph
[INFO] 14:47:10.458459 Running Tarjan on 27376 nodes
[INFO] 14:47:10.500538 Tarjan found 27275 components
[INFO] 14:47:10.566433 Variable type analysis: done
[INFO] Analyzing 4626 ucfgs to detect vulnerabilities.

I can regenerate logs if it’s needed.

— edit —
Additional informations :
The code is strictly the same, only thing change was the version.
We look a little on some new issues : they were on the files previously analyzed ( already have issues)
No change on scope of rules.

It’s why we are perplex, same scope of code, same rules but when we change the version the analysis’s result differ.



I was indeed talking about the console logs from the analysis command. Comparing before/after the fluctuation may be revealing.

Regarding your New Code Period, by setting it to previous_version and by passing a version string that changes with each analysis, you’re resetting the New Code Period each time you analyze. That’s probably not what you want. We added some string manipulation to our jobs at some point to chop the Maven version string down to just major.minor.patch and passed that as sonar.projectVersoin. If you really need the build number recorded on the analysis, there’s a separate parameter for that: sonar.buildString.


I will generate the logs again this afternoon.

Thanks for tricks. ^^
We don’t change the version number often it’s just we remark that is the trigger to reproduce the problem.

I think the new code detection is working as expected. It’s more the difference between the two analysis is not expected.

Do you have some hypothesis what could give a ‘partial analysis’ ? ( excluding change of code, rules scope changes)

—edit ----

I just compare the logs files, same logs only a log is slightly different ( the encoding log warning): the files analyzed are identical.

case with less issues (change of the version) :

[INFO] Indexing files of module 's-hes-module-yyyyyy'
[INFO]   Base dir: /var/docker_env/workspace/pipeline-moduleoldway-build/yyyyyy_feature-test-sonar-copy3.32.x/12782
[INFO]   Source paths: pom.xml
[INFO]   Excluded sources: **/jaxb/**, **/data/*, **/openmuc/**, **/xxxx/jdlms/**, **/vsdc-shared/**
[INFO] 692 files indexed
[INFO] 147 files ignored because of inclusion/exclusion patterns
[INFO] 0 files ignored because of scm ignore settings
[INFO] Quality profile for java: Sonar way - no minor
[INFO] Quality profile for xml: Sonar way

case with more issues

[INFO] Indexing files of module 's-hes-module-yyyyyy'
[INFO]   Base dir: /var/docker_env/workspace/pipeline-moduleoldway-build/yyyyyy_feature-test-sonar-copy3.32.x/12783
[INFO]   Source paths: pom.xml
[INFO]   Excluded sources: **/jaxb/**, **/data/*, **/openmuc/**, **/XXXXX/jdlms/**, **/vsdc-shared/**
[INFO] 692 files indexed
[INFO] 147 files ignored because of inclusion/exclusion patterns
[INFO] 0 files ignored because of scm ignore settings
[INFO] Quality profile for java: Sonar way - no minor
[INFO] Quality profile for xml: Sonar way

What we see for a file :

  • not all rules have been activated in the less issues usecase
  • but file was analyzed.

What we see for a rule

  • triggered for the both analysis
  • not used for all files in the case less issues ( change of version)

We have see an encoding problem ( bad character on one files) but correct it doesn’t change the behavior.



It’s been a while, so I started by going back to your OP. I’m reminded that you’re on 9.0, which - while not old - is not current. We’ve done some work on correct detection of New Code since then. Can you upgrade and see if this is still replicable?



Yes. It will take some time to upgrade due internal process. When it will be done, I will ran the test again and push the result here.

thanks for the answers. :slight_smile:


1 Like


bad news.
We do the upgrade to 9.5 this summer. The test was runned again and the problem was produced again.

1 Like

Bonjour @Justine_Lebrun,

Thanks for trying the upgrade and coming back to us. This is really weird. I’ve tried reproducing this, but no luck so far.

For your working branches (and, correct me if I’m wrong, I understand you are working with branches here, not pull requests), are you using the same New Code setting (“previous version”)? Or are you using “reference branch”, targeting the maintenance branch? And if not, could you try using that, and see if it helps?

Note that it should work, even when using “previous version” for maintenance and working branches. But perhaps you are in some edge case where this triggers a bug, and making it work with “reference branch” might give us a clue as to why it triggers.