Code Smell declared as false positives in PullRequest are not propagated to Main Branches

SonarQube
1
  • versions used (SonarQube, Scanner, language analyzer)
    Developer EditionVersion 8.2 (build 32929)

We used features false positives to declare code smells as false positives in PullRequest analysis and PR code is clean of code smells, Now the PullRequest is merged to master branch, now the code smells marked as false positives in PR branch analysis are reappeared in Master branch analysis after the merge.
We are expecting that it should be as clean as PR since those code smells marked as false positives in PR, expecting those code smells not to appear again in master analysis.

Could you pls advise what we are doing wrong here?

3

Hi,
I confirm that the resolution of the matching issues in the pull request should have been copied over to the master branch.
The results of the pull request analysis were still available in SonarQube when you analyzed the master branch after the merge? Do you have a reproducer of the problem?

4

Hi @dmeneses,
Let me explain, What we did is first time we ran the sonar scan for “Master” branch and analysis has been done and in sonarqube Project overview says that there 500 code smells, 1 Security HotSpot. .etc… status of gate first time shows passed (Even though there is security hotspot, code smells right).

  • Now PullRequest from feature branch to master is created - As part of build validation set in “master” branch the PR triggers sonar scan and we got some code smalles and security hot spot, Now we resolved them in bulk in sonar portal saying these are false positive .

  • Next code is merged to master - again there is sonar scan part of master build job, These time the code smells / other metrics declared as false positive in PR are again re-appeared in analysis of “master” branch and quality gate failed.

So question is, issues declared as false positive in PR are does not propagate to master? Once we made false positive the issues in PR and rerun the PR job sonar scan succeeded . But Same failed when PR is merged in Master since those which are marked as “false positive” are reappeared.

I hope you got senario what i am trying to explain.

5

I understood the scenario you described. The issue resolution “false positive” should have propagated to master - that’s the expected behavior.

Only case I see where that wouldn’t happen is if the P/R analysis was deleted from SonarQube before master was analyzed after the branch, or if the merge operation moved or changed the code where the issue are located in a way that prevented SonarQube from matching the issues between master and the P/R.

Is this a behavior that you always see and are able to reproduce, or only happened one time? Any chance you could provide a simple reproducer of the problem?

6

@dmeneses thanks for the response. I will try to reproduce the issues and let you know.

7

i did encountered scenario mentioned above by Kori but the differences is the quality gate doesn’t failed after I merged the changes into master branch (Issue on P/R has been marked as false positive)

Just the issue resolution doesn’t propogate to master branch