Bug migrated to master from another branch without merging


We are using Sonarqube development edition version

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

But this branch is newly created PR that was not merged into master yet. Moreover, QualityGate check succeeded on this PR:

How it could happen? What means “copied” in this case? And how we can prevent running into this issue in the future?

If you need any additional information, I will gladly provide it.


Does any one looked at this issue? Please, let me know if you have any information/guesses/questions.


What conditions are in your Quality Gate?


Hi, @ganncamp !
Here is the quality gate conditions list used for this project.


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.


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.