which versions are you using (SonarQube) - 9.4.0.54424
what are you trying to achieve - Checking Code smells between branches but with same code
what have you tried so far to achieve this - Checking the settings between Master and feature branch. Master branch compares with previous version and feature branch compares with project settings
issue Explanation : Service Locator class appears to be Deprecated Code in feature branch but not in master branch
feature branch : [Remove this use of âServiceLocatorâ; it is deprecated]
master/main branch : doesnt show this as deprecated
Please confirm the rules or settings which i need to do make master accepts deprecated code similar like feature branch
I donât understand the problem. You say the deprecation hasnât yet reached your main branch. So itâs quite expected that you wouldnât see an issue for the use of deprecated code.
I will make little better,
Main and feature branch has same code.
Just in feature branch shows some classes in the code as deprecated [ Remove this use of âServiceLocatorâ; it is deprecated], and expected code smells are there
In master branch having exact code of having classes âServiceLocatorâ, but it doesnt show as deprecated code, because of these code smells are not there for this.
it is contradictorily, code smell showing in one branch but not on the other.
This means in master branch, somehow rules/policy doesnât allow to show the code smell.
After every release, release build will be merged to main branch, so it triggers build automatically in main branch. this build runs successfully 14 days before
Why master/main branch doesnât show code smell for the line import domaininterface.service.ServiceLocator;
and same code/line in feature branch shows as code smell import domaininterface.service.ServiceLocator;
When we build from jenkins last time on main branch, Sonarqube wasnt identified that service locatior as code smell, but just on feature branch it shows as code smell
Also can you explain what you mean i have to do this activity called âanalyse and marked deprecatedâ ? Is this manually i need to go to the code in sonarqube in main branch, and mark as code smell. Thought sonarqube does this by its own
So it sounds like this was the sequence of events:
analyze main
mark ServiceLocator@Deprecated
create & edit feature branch
analyze feature branch
Your question is why the deprecation warning is showing up in the feature branch but not the main branch.
When feature branches are first analyzed, they sync issues from their base branches (typically main). But if the issue doesnât exist on main, it canât be synched in to the feature branch.
As I said earlier, best practice dictates that you analyze each branch - and especially main - regularly. So IMO you should edit your procedures / pipelines to analyze main after every commit.
Thank you for your assistance so far! Iâll try provide some additional infoâŚ
ServiceLocator has been deprecated for years. It will certainly have been deprecated long before we were even using Sonar.
Every commit (push, rather) is scanned, be it a feature, release or master branch.
The last scan on master was Jan 23, and this issue predates that.
Feature branches are cut from master.
In essence, what weâre seeing is a different report for master and a feature branch - even when they share the very same commit id (Iâll try get this double confirmed by cutting a brand new branch from the same point that master was, and still is, at the last time it was scanned.
One point which may be of note is that feature branches are always compared to master, and master is compared to the previous version.
Thanks again for your help, please do let me know if this additional info changes anything.
Welcome to the community, and thanks for this clarity!
How do you make this comparison? With the sonar.newCode.referenceBranch parameter in the first analysis? Or is that set up in the UI after the first analysis?
Are other issues raised in main in those files where the deprecation issues are not?
Can you compare the Scanner Context from main analysis (look on the Background Tasks page, in the cog menu) with one from a branch analysis and make sure they have the same sonar.sources and exclusions definitions?
I think Iâve uncovered some more clues, or at least some more weird data to ponder over.
Comparison rules were set in the UI some time back, long after weâd done our initial scans. Iâve included a screenshot of those setting below.
Unfortunately, the Scanner Context for the scan on the 23rd Jan (of master) is no longer available - records only go back as far as the 31st Jan. So, I did fresh builds of both master (still on the same commit id) and the feature branch (same as master), to make sure weâre dealing with like for like data. The contexts are exactly the same apart from the branch name (and workspace folders on the CI side)
Of course, now both results are, as expected, (almost*) exactly the same.
Looking first at master
Hereâs the original scan for the 23rd Jan, indicating 85k code smells:
So it appears that before we even begin to look at the issues arising in the feature branch (based on the same commit), we can already see discrepancies between two separate scans of the same code.
Finally the stats for the overall code (todayâs build):
Iâm happy to put the anomalous build aside as âsomething glitched out on the 23rdâ (we can blame networks/the DBAs!), but todayâs exercise still raises questions I canât answer.
Appreciate this has turned into a mammoth post, trying to be thorough as I can!
Iâm a little lost. Weâre down to understanding why there are three fewer issues detected in the branch?
Iâd suggest starting to track this by using the facets on the issues page, starting by checking the sum of Unresolved + False Positive + Wonât Fix issues, which youâll find in the Resolution facet.
Given I canât reproduce the scan which resulted in 85k smells, rather than 92k, yes, weâre down to minor discrepancies which are probably not worth spending heaps of time investigating (unless we wish to investigate why 2 scans of the same master branch/commit produce different results over time).
I donât dispute that something looks weird with the original evidence, but it could be a number of other reasons⌠Although they were from the same commit, the original scans of master and the feature branch were a week apart. Was there an upgrade in that time or a Sonar ruleset change which caused a difference? I donât know. At the time, were they built on slightly different build agents with differing versions of java/maven? I canât be sure.
I will propose we park this until it happens again, at which point we can gather better evidence to investigate.
Thanks once again for your insights, and I hope we meet again if we resurrect this issue.
