We are using Sonarqube development edition version 9.8.0.63668.
In our case sonarqube does 2 scans on each PR (PR scan and full branch scan) to prevent merging unexpected issues into master.
Today we have faced with unexpected Sonarqube behavior. Our nightly job on CXX project was failed due to quality gate with new code smell into master branch.
When I opened issue history, I’ve noticed that issue was copied from another branch
Thanks for sharing your Quality Gate. Since the issue in question is a Code Smell, it could have slipped through the standard ‘Maintainability Rating is worse than A’ criterion in the build-in Quality Gate. But you’ve also got a condition on Minor issues, so that should have caught it.
I’m over my head at this point, so I’m going to flag this for more expert eyes.
Hi,
SonarQube doesn’t know when PRs actually get merged, since it doesn’t get that information from the code repo being used (github in your case).
So it guesses that an issue is merged from a PR to master when:
The same issue is present (open) in the PR, and the PR targets master
The issue hadn’t been seen in master before
So it could happen that the issue was coincidentally introduced into master, at the same time when it already existed in the PR.
The same algorithm applies for branches with the New Code Period set to “reference branch”, and using master as the reference.
The goal is that manual changes done to issues are not lost, and are moved to the master branch. Note that the fact that SonarQube indicates that the issue was copied from another branch to master is not the reason why the issue exists in master. It means that the issue is present in the code analyzed as master, and sonarqube just copied the issue attributes from somewhere else instead of initializing it with all default values.