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
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.
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?
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.
