We are using sonarcloud.io 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’ https://sonarcloud.io/project/issues?id=xxx&branch=develop&resolved=false&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
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?
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
This was from 2 years ago - and this is expected as the commits to the ‘develop’ branch is using the results from the ‘Overall Code’ tab and not ‘New Code’.
The sonar analysis fails in GitHub. This is because it uses the results from overall code and not new code. The last screen shot is from the PR showing the analysis against ‘new code’.
I’m a bit confused. The middle screenshot, the one with the failing Quality Gate, clearly shows failing New Code conditions.
If the problem is that old code is being analyzed as new, then that’s a question of the SCM blame data available to analysis.
Going back to your OP, you mention “automatic analysis”. To be clear, you haven’t configured analysis in your CI, SonarCloud is handling the checkout and analysis for you?
Going back to your OP, you mention “automatic analysis”. To be clear, you haven’t configured analysis in your CI, SonarCloud is handling the checkout and analysis for you?
The analysis is configured in our CI. This was before netframework could be run automatically
The middle screenshot, the one with the failing Quality Gate, clearly shows failing New Code conditions.
Exactly. And this is the problem as the ‘develop’ branch is the ‘main’ branch. The screenshot below is the PR that generated the merge to the develop branch. This PR reported 0 New Issues. The subsequent merge of that PR then displays 11032 New issues. This is incorrect. This is the issue I am trying to resolve. SonarCloud.io does not show these new issues on the main branch as New Code.
Also, when did your New Code Period start?
This is set for a previous version. I do also have a question about that. We cannot remove an old version and this appears to be tagged or stuck on the latest commit. See my screenshot below. 24.5 is set to a commit from today but can only be edited. The version we are running is 24.11. This can be edited and deleted. Can you tell me how to remove 24.5?
This thread has been going on - intermittently - for 2.5 months & I feel like the target keeps moving.
Again, if old code is showing up as new, that’s an issue of your checkout. Can you share your analysis log?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
We try to keep it to one topic per thread. Otherwise it can get messy, fast and this thread is already plenty messy. If you want to pursue this, please create a new thread.
