Same Code in Master & feature branch but Code smell is higher in feature branch

gurukathirvel · January 30, 2023, 5:05pm

Must-share information (formatted with Markdown):

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

ganncamp · January 31, 2023, 5:24pm

Hi,

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.

BTW, what language are we talking about?

Ann

gurukathirvel · February 1, 2023, 10:09am

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.

FYI, this is Java code

Hope this explains

ganncamp · February 1, 2023, 3:58pm

Hi,

Have you analyzed your main branch since the deprecation?

Is the scope of analysis the same (all the same files) for main and the branch?

Ann

gurukathirvel · February 6, 2023, 10:08am

any new feature branch cut from master branch has this issue, create release branch from feature branch and then this release branch merged to master.

So in these process, feature & release branches shows the deprecation code but in master it doesn’t.

We didnt analyse master branch because it doesnt show code smells, almost 5k additional code smells show in feature but not in master

ganncamp · February 6, 2023, 6:40pm

Hi,

When’s the last time you analyzed your main branch?

Ann

gurukathirvel · February 7, 2023, 9:55am

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

ganncamp · February 7, 2023, 4:16pm

Hi,

And was the deprecated code already marked deprecated when you analyzed 2 weeks ago?

BTW, best practice would have you reanalyzing after every commit. And I think that would make this problem go away too.

Ann

gurukathirvel · February 8, 2023, 1:01pm

But relating to Code Smells

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;

ganncamp · February 8, 2023, 3:04pm

Hi,

What language are we talking about?

And again, when you last analyzed the main branch, had ServiceLocator been marked deprecated already?

Ann

gurukathirvel · February 8, 2023, 4:48pm

Same application, Java code

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

ganncamp · February 9, 2023, 1:15pm

Hi,

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.

HTH,
Ann

denham.coote · February 15, 2023, 6:54pm

Hi Ann

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.

Best,
Denham

ganncamp · February 16, 2023, 1:26pm

Hi Denham,

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?

Ann

denham.coote · February 16, 2023, 9:01pm

Hi Ann

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:

And here’s a scan of the same commit ID I ran today, showing 92k:

The activity page confirms that it’s the same version being built since the prior version in November:

…to be continued in another post as I can only post 3 images as I’m a new user.

denham.coote · February 16, 2023, 9:02pm

To be absolutely sure both of these builds come from the same code, I looked at the build logs and confirmed that they shared a commit ID

37:

38:

…to be continued in another post as I can only post 3 images as I’m a new user.

denham.coote · February 16, 2023, 9:04pm

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):

Looking next at the feature branch

Now, things start to look a little bit better:

The overview page for the feature branch present the same stats as master:

* However, you may have noted above I said they were almost the same…

On master: 92,209 issues

Yet on the feature branch: 92,206 issues

These builds are moments apart, from the same commit ID, yet they’re showing differing issue counts?

Finally, the project/branch settings for new code:

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!

Best,
Denham

ganncamp · February 17, 2023, 1:06pm

Hi Denham,

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.

Ann

denham.coote · February 17, 2023, 8:08pm

Hi Ann

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.

Best,
Denham