Default branch is using overall code and not new code

We are using for automatic static analysis against a GitHub private organisation repository. The PR analysis is working for new code but after changes are merged to the main branch this runs analysis for overall code. How do we configure this to only run for new code? A code version has been setup but the link on the main branch (after a PR has been merged) fails and shows all the ‘overall’ issues. The link that is displayed looks correct as this has a paramter ‘sinceLeakPeriod=true’

How is this expected to behave? I was expecting this to only show ‘new code’

The only odd thing I can see regarding teh code version is that we appear to have a ‘sticky’ version. See screenshot. We cannot remove the value 23.5 and this always remains against the latest commit. Could that be the problem? How can we remove this and have the main branch report ‘new code’ issues and not overall code. The end result is that we have PR results passing the quality gate and then merges to the main branch failing


Welcome to the community!

Is this a question of only showing new code, or only analyzing new code? Because for short-lived branches, we analyze everything but limit the display to new code. For long-lived branches we analyze everything and show everything.

So it’s possible that what you intended to be a short-lived branch was initially misunderstood as a long-lived branch. (And branch type is immutable.)


Thanks Ann. That makes sense and perhaps is the best practice but wasn’t what I was expecting.

The ‘main’ branch is long lived so when we commit to this branch, i.e. merge a PR, it is analyzing everything and results in a failing check in GitHub as our quality gates are setup for new code. The short lived branch (PRs) will pass the checks as they are only analyzing new code but the resulting commit fails against the main branch. This isn’t what I was expecting. Is there a way to configure this so that the long lived branch uses the results from new code? Or would you recommend turning off the status check in GitHub to get around this?



I’m not sure I understand. Your Quality Gate is failing because of issues on New Code not raised in PR/short-branch analysis? Or because of new issues raised in old code after merge?

Unfortunately, that’s somewhat expected, as explained in this guide.


The former. The quality gate fails due to existing issues in old code. My understanding from your response is that this is because this is a long lived branch.

Our development cycle involves developers creating a feature branch from the main branch and creating a PR when it is ready for review. The PR is run against Sonar (new code) and passes. The PR is then merged to the main branch and Sonar fails. This is not what I was expecting. The PR analysis only looks at new code. The main branch analysis returns all issues from the overall summary.

Is there a way to avoid this so that the result of the merge to the main branch is the same as the result of the PR?


Are these old issues in old code or are they new issues in old code?

As I said before, finding new issues in old code after merge is, unfortunately, expected.


Hi Ann.

These are old issues in old code. That is what I was describing when I mentioned

The quality gate fails due to existing issues in old code.

If I understand your point this is not expected. Can you help me understand how to configure sonar so that commits to our main branch do not show results for old issues in old code


Can you give me a screenshot - reacted as necessary - of one of these issues? I’d particularly like to see the issue date. E.G.: