Issues show up in short lived branch that were in master but now are removed from master

[donnib]

Hi,

I see issues in short lived branches that somebody else removed in master, what could the reason be to that ? The author did not touch that part of the code in the short lived branch.

Is this a bug ? I run 

6.7.1.35068

Developer Edition.

/donnib

[G. Ann Campbell]

Hi donnib,

In a short lived branch you're going to see reported the issues that aren't present in the base branch, so if the issues were removed from master between branch creation and initial analysis, this is expected.

Ann

[mi...@marinescu.dk]

Hi Ann,

Why is that the case ? I mean SonarQube can see the diffs between the target branch and my branch so it should only show issues based on that changed/added code and not the whole repository. Is this something you have in mind changing ? If this is not changed there will be many false alarms in the branch making it hard to see the issues that developer made. I don't think this is the right approach. 

/Mihai

[G. Ann Campbell]

Hi Mihai,

There's a sync of issues at the branch's first analysis (this is actually the case for both types of analysis) and not again. Theoretically, you shouldn't need to re-sync for a short-lived branch because it's ... short-lived.

Ann

---

G. Ann Campbell | SonarSource

Product Manager

@GAnnCampbell

https://sonarsource.com

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/pbEgnPIT0g8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/363824f1-955a-4260-bda5-172d2c64ccd3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mi...@marinescu.dk]

Hi Ann,

"Theoretically" yes but in practice its much different. As soon as you branch new things come in the target branch and that is happening very quickly. What's the reason for not changing this approach when it's clearly not the best approach ? The main question for a developer is to have SonarQube to answer the question "what issues have i introduced in the new code i just made". The tool does not answer this question in a clear way, sometimes it gives you other answer which is not what the developer wants to know and worst it makes the developer waste time to figure out why these issues come up when in reality they have nothing to do with him.

/Mihai

To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.

[Colin Mueller]

Hello!

@Ann: Question about the functionality here: If a Quality Profile changes, but the master branch has not be rescanned since then, will the new branch show issues related to old code but that nonetheless issues not present in the master branch? If that's not the case because of backdating based on SCM info, could that still happen for other scenarios (no SCM, TFVC, etc.)

I think Mihai makes a good point that the current functionality could be confusing. It looks like SonarSource had considered this during inception of the Branch Plugin (https://jira.sonarsource.com/browse/MMF-1058). I'm curious about what solution was/wasn't landed on and how it applies to Mihai's situation.

Colin

[G. Ann Campbell]

@Colin, thanks for digging out that MMF. I had forgotten about it. It looks like we did do some work in this area. 

@donnib, you said originally

I see issues in short lived branches that somebody else removed in master, what could the reason be to that ? The author did not touch that part of the code in the short lived branch

Did the developer do any work in a different part of that file? Or were the branch changes totally unrelated? Also, what's your SCM? It seems that 

• SONAR-9837

 might be relevant; it appears that only the Git and SVN integrations fully support figuring out which changes don't relate to edits in the branch.

@Colin, regarding your Quality Profile question, I'd have to do some testing (which isn't possible for me this afternoon), but assuming you're using either Git or SVN this should work as expected. 

[mi...@marinescu.dk]

Hi Ann,

1. No the developer did not change those files at all but i understand why that shows as changes since you write in the documentation here : https://docs.sonarqube.org/display/PLUG/Branch+Plugin following :

Short-Lived Branch

The issues visible on the short-lived branch are the new issues corresponding to files modified in the branch.

Modified files are determined based on the checksum of each file on the sonar.branch.target and the short-lived branch.

And i understand above that when the checksum between the short lived branch and the target is changed then you assume a file is changed but that's VERY simplistic because that will be the case very often when short-lived branches get merged into the target branch. You should instead use SCM to figure out what files has been changed and basing it on a checksum between the two branches will be quickly outdated.

2. Regarding SCM, we use Git.

For us this is a real deal breaker because that means the developers has to rebase/merge target quite often to get a result which is does not have a lot of noise. No matter how often they do they will see noise in the results leading to questions e.g waste of time until they realize "ohh those are not my changes but somebody else in target branch".

/Mihai

[mi...@marinescu.dk]

So what is the conclusion of this ? SonarSource will not do anything about this, it works as designed ?

[G. Ann Campbell]

Hi,

Let's say that there's no conclusion yet. Remember that this feature is quite new for us and we're still discovering limitations and at the same time working on it quite actively.

Ann

---

G. Ann Campbell | SonarSource

Product Manager

@GAnnCampbell

https://sonarsource.com

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/pbEgnPIT0g8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/62505558-6816-41df-b778-5c2a83b8a061%40googlegroups.com.

[nicolas...@sonarsource.com]

Hi Mihai,

I don't think it's fair to ask for firm conclusions/actions when Branch Support still is a relatively new improvement, that we are actively collecting feedback on, and also actively using ourselves. That being said, going through past posts here, I would like to mitigate the risk of you thinking that the Branch Plugin is only doing checksum comparison (per documentation excerpt you quoted). That same documentation also mentions:

But if you use Git or SVN we can better track the new files on short-lived branches and so better report new issues on the files that really changed during the life of the short-lived branch.

And as shared by Colin in a previous post, MMF-1058 is an essential read in that respect. It shows how Branch support is capable of advanced git lookup on the branch , with a bunch of rebase/merge scenarios that are definitely meant to be supported.

All in all, beyond the descriptions and behaviour summaries done so far, I would advise to base further discussions on actual repro cases. The reason I shared these pointers is to highlight clear will to be as accurate as possible regarding change detection on branches, including with the fetch of actual SCM-specific info (if available of course). If you still identify a specific scenario that seems to produce undesired behaviour, then do share the steps to reproduce in a dedicated thread, and we'll surely be happy to give it a look and see how things could be improved in future versions.

Best regards,

Nicolas