7.2.1 Enterprise Branch Analysis not detecting fixed code on subsequent scans

branches
vsts

(Bill Benjamin) #1

Overview

  • SonarQube 7.2.1 Enterprise with VSTS (C#)
  • Issues not resolved/re-opened despite the fix being implemented. Snippet displays old code. No errors displayed

Steps to Reproduce

  • Run initial scan on master branch
  • Run scan on Develop Branch (Long-living branch)
  • Run scan on feature branch (short-living branch) - 2 new issues reported
  • Make suggested changes to VSTS/Git feature branch
  • Mark the 2 issues as resolved in SonarQube
  • Run second scan on feature branch
  • Issues in SonarQube are marked Re-Opened. Viewing the snippet in SonarQube displays code from the initial scan. It is as if SonarQube doesn’t recognize the changed code even though I confirmed the code in the short-living branch has been updated.

Summary

We have a Master branch that is being analyzed. There are MANY issues on the Master branch. There is a branch off of Master called Develop. Both of these branches are long-lived branches and in sync.

Off of Develop, I have a short-lived branch called “feature/pfemp”. We modified this branch. 2 issues were returned when this branch was scanned after modification.

We created a new branch off of feature/pfemp called pbi/12345. We resolved these two issues in this new branch and created a Pull Request to merge the changes into feature/pfemp. A scan ran on the Pull Request and returned 0 new issues.

We then ran a new scan against feature/pfemp, but the issues in SonarQube are still being displayed. When I click into them, I see a snippet of the code before we made the fix. When I look at the code that is in feature/pfemp, I see the updated code. I then tried marking the issues as fixed. Re-ran the scan, and the issues were updated to Reopened. So it seems like SonarQube is not picking up that the code changed, even though it has.


(Nicolas Bontoux) #2

Hi there,

Thanks for the detailed summary. Two main comments at this stage:

Off of Develop, I have a short-lived branch called “feature/pfemp”
We created a new branch off of feature/empfv3 called pbi/12345
We then ran a new scan against feature/pfemp

You lost me somewhere here :wink: I read that you’ve got 2 issues on feature/pfemp , but suddenly you explain that you branch out off feature/empfv3 , only to then rescan feature/pfemp. Maybe it’s just a typo, but it’s worth double-checking/explaining what this feature/empfv3 branch is.

This is definitely not expected, meaning that if the analysis is successful, then the code analysed should definitely be reported back to SonarQube. The starting point for any troubleshooting here (after double-checking the first point above) would be to check the behaviour of the analysis:

  • in VSTS, check logs of the analysis of feature/pfemp, make sure that it was successful and reported status to SonarQube
  • in SonarQube, make sure that the corresponding Background Task succeeded
  • all in all trace down what happened to this specific analysis of feature/pfemp, from code checkout + analysis , to processing on SonarQube side

Clarifying both points above should already shed some light on the what’s going on and help you narrow this down.


(Bill Benjamin) #3

Hi. Thanks for your response! The first point in your response was, in fact, a typo. Sorry about that! I’ve updated the post to remove the typo.

For the second point, the scan did complete successfully and is reporting back as successful scan. It even re-opens the issues that have been corrected in the branch that the scan is run on. To me, this feels like a bug, but perhaps I am doing something wrong.

Aside from the successful scan log from VSTS. Is there somewhere else I can look to see what might be happening?

2018-08-06T21:23:21.0471786Z INFO: Analysis report uploaded in 94ms
2018-08-06T21:23:21.0482129Z INFO: ANALYSIS SUCCESSFUL, you can browse http://fhcapadpd02.fhlbc.loc:9000/dashboard?id=mpf.empfadmin&branch=user%2Fbbenjamin%2Fsonartest&resolved=false
2018-08-06T21:23:21.0482608Z INFO: Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
2018-08-06T21:23:21.0482813Z INFO: More about the report processing at ****
2018-08-06T21:23:21.0577458Z INFO: Task total time: 19.544 s
2018-08-06T21:23:21.1037214Z INFO: ------------------------------------------------------------------------
2018-08-06T21:23:21.1037849Z INFO: EXECUTION SUCCESS
2018-08-06T21:23:21.1038074Z INFO: ------------------------------------------------------------------------
2018-08-06T21:23:21.1038340Z INFO: Total time: 20.919s
2018-08-06T21:23:21.2462994Z INFO: Final Memory: 42M/1092M
2018-08-06T21:23:21.2463523Z INFO: ------------------------------------------------------------------------
2018-08-06T21:23:21.3963199Z The SonarQube Scanner has finished
2018-08-06T21:23:21.4047404Z 16:23:21.398 Creating a summary markdown file…
2018-08-06T21:23:21.4072627Z 16:23:21.398 Analysis results: ****
2018-08-06T21:23:21.4077010Z 16:23:21.398 Post-processing succeeded.


(Janos Gyerik) #4

Can you please clarify the following. On SonarQube, if you go to the PR feature/pfemp, and look at the Code tab, do you see that updated code that has the fix?

Based on your description, in particular that after you mark issues as Fixed -> analyze -> they get Reopened, it seems that the unchanged code was analyzed again. Looking at the Code tab on SonarQube should make that clear.

In short, I would verify that the correct branch is being analyzed, with the right content and the right name, and then verify the content at SonarQube side matches correctly.


(Bill Benjamin) #5

Hi Janos. Thanks for the thoughts. I can confirm that it appears that SonarQube has analyzed the previous code.

Upon further inspection, the code that was fixed resides in a different solution than the where the project being analyzed resides. However, the project that was updated is referenced by the solution being analyzed, so it is being returned in the analysis. There are some weird broken references that I think may be the culprit of this.

At this point, I’m going to call it faulty code and work to confirm that this is working properly in cleaner situations.