We are using SonarCould integrated with AzureDevOps and started failing the PR build if the Sonar Quality Gate isn’t passed. The applications are several years old and do have existing issues which we are working on separately. For the new development/bug fixes, the PRs enforce the condition for the new code. It seems that “Maintainability Rating”, “Reliability Rating” and “Security Rating” doesn’t follow the “new code” paradigm. In one of the project, the PRs list these as failed and when we look at underlined issues, all of those are in the area of code not touched in the current PR. The Issues tab lists the issues and tags them several months/years old. It seems that the whole file is picked for these three metrics as “new code” rather than the just one line or one method that was updated. Is this by design? Unfortunately, it isn’t handful of issues, as some of the files are large and can have 20-30 issues. If these were handful, we could ask developers to fix but rather large number creates problem as it isn’t just developer’s time, the testing/QA surface balloons significantly.
Any ideas are appreciated. We are on Enterprise plan if that matters.
Here is the gate that is applied.
Conditions on New Code
Conditions on New Code apply to all branches and to Pull Requests.
In SonarQube Cloud PR analysis, all issues that are new in the file versus the base branch will be reported against the PR. So if you haven’t analyzed the underlying branch in a while, it can cause this behavior.
Thanks Ann. The main branch is being analyzed every night and I have confirmed that the runs have been successful. In those analysis, “New Code” seems to be detected correctly as we notice that while “Overall Code” has many issues, the “New Code” only fails due to code coverage below 80% (around 70%) which is fine (we had to allow some PRs go through even when they did not pass Quality Gate). However, PR analysis on the same target branch reports new “Maintainability Rating”, “Reliability Rating” and “Security Rating”. None of the issues are due to the PR being analyzed, those are existing issue already reported in the “Overall Code” for the main branch.
Have we configured it correctly? This is how we have it
Nightly analysis on the main branch (in some projects an additional branch)
PR analysis during the build/test
New Code is defined as N days old (should matter only for main branch analysis)
Your new code definition doesn’t matter for PR analysis; PRs will always be compared to their target branch.
Can you share the analysis log of your PR, redacted as necessary?
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.