New issues on old code in short-lived branch

SonarQube
1

Hi

I am using SonarQube SonarQube v7.9.1 (Bulid 27448) Enterprise edition and Sonar Scanner v3.0.3.778. And C++ Build wrapper v4.7

I have noticed that on our short-lived branch (SLB) called “integration”, when I look at the analysis (which I believe is an analysis of the delta between this branch and branch “master”) I see some issues on lines of code that were written 5 years ago. Sonar tells me it is 5 years ago.

For example, “Split this 171 characters long line… [See Rule] 5 years ago L167”

Why is it showing me a line of code written 5 years ago?

The master branch is no more than 4 weeks older than the integration branch, since integration is merged to master roughly once a month.

Q1. Please can you explain why Sonar is including a line from 5 years ago?

Q2. Please can you explain what Sonar is trying to tell me here?

Surely Sonar just sees the lines of code in branch integration that are new/changed compared with master, and analyses those lines. So this long line, which was written 5 years ago, should surely not appear in the analysis. Or should it? If so, why?

Finally, our definition of “New code” is set to “previous_version” for our project.

SonarQube appears to tell me that the analysis for branch “integration” is “From master” - that’s printed at the top of the web page - so I assume it is a delta of branch integration compared with branch master.

In fact, according to the docs (https://docs.sonarqube.org/7.9/branches/overview/) for a short-lived branch, “…there is no way to set the New Code period; everything that has been changed in the branch is new code.”

So I really am not sure why Sonar is analysing lines of code that were last changed 5 years ago.

Update: I see that under the tab “Issues”, on the left-hand pane there is a twistie called “Creation Date” with a bar graph showing me dates and the option to click on All or New Code. This gives me control over the range.

So now I realise that I was misinterpreting the information I was told here that a SLB is a delta scan from master. What it actually is is a delta from when the branch was branched off of master, not the current state of the branch versus the current state of the master branch.

From what I can see, for a given SLB, we are looking just at the lifetime of that branch perhaps, and the analysis shown is nothing to do with master? Ah, I think the issue is that our integration branch was branched off of master 5 years ago, so it’s not really supposed to be a SLB. So we see ALL issues in our integration branch - it’s not a delta as I’d imagined but just a delta between what happened in the last 5 years since the branch was branched off of master.

Please can someone confirm?

Thanks in advance.

2

Hi,

SonarQube tries to detect changed code between the branch and it’s target.
Are you using git? If the scanner has access to git, this ‘diff’ should be precise and match what you see in your code repository.

Only files with lines detected as changed will be shown in the SLB. So that means that you can have lines that were not modified in files that contain other lines that were modified. Is the line in question highlighted as ‘new’ with a yellow background? Do all the lines highlighted as ‘new’ are correct? A screenshot would be helpful.

Any issue that involves a changed line of code will be shown in the SLB. Note that the issue might involve other locations other than the main line where it’s shown in the UI.

So now I realise that I was misinterpreting the information I was told here that a SLB is a delta scan from master. What it actually is is a delta from when the branch was branched off of master, not the current state of the branch versus the current state of the master branch.

No, it should be a delta compared to the HEAD of master. If git is being used, make sure that the local reference to the master branch is present (fetched) and up to date.

3

Hi Duarte

Yes we are using git. I do a git fetch origin master:master and so the master branch is up-to-date.

No, the line of code in question is NOT yellow. So I assume it is NOT considered New. But Sonar tells me there is an issue with the line nonetheless.

Regarding all the lines that are yellow: I see some yellow blocks of code that are from 1 year ago - I’m not sure why they are yellow and considered to be new. That seems odd to me.

The master branch is 6 years old and the integration branch is 5 years old. When the integration branch is an SLB, I see changes dating back 5 years. Under the twistie “Creation date” it defaults to All code. If I set it to New Code then I have to change the date range (or course) via the little bar chart to tell it what date range New Code is. So it makes sense to me that it is looking at the whole lifespan of the SLB. The SLB branch is 5 years old remember and we are using an old SonarQube, namely version 7.9.1

So it feels like Sonar is working as I described. Furthermore, I read the following from your colleague G Ann Campbell (@ganncamp) which backs up what I said about the analysis being for “what has changed since the branch was … branched off of the main branch”:

See The last analysis has failed - #8 by ganncamp

“What you’ve shown is a Short-lived branch (SLB). The assumption is that all that matters to you is analysis of what has changed since the branch was … branched off of the main branch.”

AND

“BTW SLBs and PRs don’t show delta from the last scan of master, but from their branch points”

Up to now my experiments back up what G Ann Campbell (@ganncamp) says, but I am still checking things in this respect.

Please could you confer and clarify what Sonar 7.9.1 is actually doing?

Thanks in advance.

4

Hi,

The way SonarQube classifies code as ‘new’ changed in v7.4. The post from Ann was before that. See SONAR-11151. In 7.9 the lines classified as ‘new’ should be based on a git diff between the SLB and master. Please compare what you see in SonarQube with the result of doing a git diff - it should match.

I made make a mistake in my previous post when describing how SonarQube decides what issues to shown in SLB. This changed in 8.x for pull requests and I described the new behavior.

In v7.9, If I remember correctly, SonarQube compares issues found in the SLB with the issues present in the target branch. Only issues that don’t match any issue in master will be shown (with the assumption that these are being introduced in the SLB).

I hope this helps.

5

Hi Duarte

Thank you for the clarification regarding G Ann’s comments being for a much older version of Sonar.

For some reason, it seems that our v7.9.1 SonarQube is exhibiting the old behaviour, as per: “Otherwise, fallback to using the changed dates of each line, comparing with the time when the branch was created.”.

Q1. Can you think of any reason why our Sonar v7.9.1 might be exhibiting old behaviour?

Q2. Would this issue be caused by the C++ scanner? Or by the SonarQube analyser server?

Q3. How can I check that Sonar is actually doing the git diff that you say it should be doing? Where does it say that Sonar found X issues in master and Y issues in integration, and that the number of new issues is Y - X? I think Sonar is failing to do this for us for some reason.

Q4. What should I look for in the scanner stdout and the Sonar logs?

I notice that when looking at the analysis screen, the number of issues does not change when I click on “New Code” as opposed to “All” under the twistie named “Creation Date”. This seems wrong to me. It is as if our Sonar does not know what New code is. Also, it defaults to All, which is odd I think.

I believe (but I need to confirm) that the scan results were no different when I added the step to fetch master, namely: git fetch origin master:master
I added the above step because before that I saw in the logs that it said, “Could not find ref ‘refs/heads/master’ in refs/heads,…”. However, I recall fetching master didn’t actually affect the number of issues reported, so it feels like Sonar is not doing a git diff with master even though it clearly wants the master branch to be present. I will check and confirm.

As you know, we see 5 year old changes in the analysis of our integration branch which was branched off of master 5 years ago. Yet both master and integration branches have been updated recently: the master branch about a month ago, the integration branch about a week ago. So I would expect to see only issues in code that was written in the past week, no older.

We have an integration branch which is merged to master every month. We have feature branches that are branched off of integration, never directly off of master. So Sonar sees that the feature branch branch point from master is 5 years ago, because that is when integration was branched from master. So because Sonar is falling back to the old behaviour, it means even our feature branches have 5 year old issues in them.

What are your suggestions for things we can to do investigate this further?
What tests or experiments would you suggest we try?

How can we force Sonar to do the git diff between integration and master for the HEADs of the branches as they are today, instead of it looking at the branch point when integration was branched from master, which was 5 years ago?

Thanks in advance

6

Hi all,

Just a reminder that 7.9.* is EOL. @willb Duarte mentioned that this behavior has changed in current, supported versions.You should upgrade to either the latest version or the current LTS at your earliest convenience. Your upgrade path is:

7.9.1 → 8.9.2 → 9.1 (last step optional)

You may find the Upgrade Guide and the LTS-to-LTS Upgrade Notes helpful. If you have questions about upgrading, feel free to open a new thread for that here.

 
Ann

7

Hi Duarte

I have simplified things and now we have our Main branch set to integration and I am looking at the delta of a SLB named feature123. Branch feature123 was branched off of branch integration directly about 2 months ago. Things look a lot better now - far fewer issues found.

I see one file, myfile.cpp, has changes in it on lines 100-104. These are shown highlighted in yellow and this is correct, i.e. these are changes that were made in this feature branch.

I also see that on Line 61 that Sonar found an issue, highlighted in pink. However, this line was last changed 5 years ago so the issue is from 5 years ago.

Is it the case that Sonar is showing me the issue in question because that line is being called by a newly changed line of code in this feature? (There is a changed line in another file in this feature that is calling that Line 61 that has the issue on it, so this might explain it. Does it?)

OR

Is it a bug?

The Sonar issue in question is this: “Rename this member function so it doesn’t hide an inherited non-virtual function or make it virtual in the base class. cpp:S1242”

Confirmation as to whether this issue being included in the scan results is correct or not would be much appreciated.

Thanks in advance.

8

Will,

About Q1-4 in your previous post, you can enable debug logs in the scanner and see if there are any warnings about the scanner not being able to use git to find the changed lines with it. I could have a look at it if you share the logs (privately if you prefer).
As I wrote before, if the lines highlighted as “new” shown in SonarQube doesn’t match what you get with the command git diff, most likely there’s a problem with it.

I also see that on Line 61 that Sonar found an issue, highlighted in pink. However, this line was last changed 5 years ago so the issue is from 5 years ago.

Is it the case that Sonar is showing me the issue in question because that line is being called by a newly changed line of code in this feature? (There is a changed line in another file in this feature that is calling that Line 61 that has the issue on it, so this might explain it. Does it?)

OR

Is it a bug?

Yes, that could be it. If the issue involves any location modified in the SLB, it will be shown in the SLB. That’s because the change in the SLB may have caused the issue to show up, even if the change is not at the main location where the issue is shown.

I agree with @ganncamp that you should upgrade to v8.9 LTS (although note that you won’t have short lived branches anymore). There are a number of bugs that were fixed and it makes figuring things out much easier as we don’t have to take into account all the things that have changed.