We have setup pull request analysis for C# .Net code. It is observed old code(unmodified) is being considered for analysis which is not expected, this is blocking us from using quality gates.
The new code condition is set based on the “number of days” condition which is set to 1.
Even then we PR/short branch analysis reports issues that are present in old code (which are not updated\edited as part of the pull request), because of this issue we are unable to enable quality gates.
Following tasks are used in azure devops pipeline:
Prepare analysis for sonar cloud
Run code analysis
Publish quality gate result
ALM used: Git in Azure DevOps
CI system used Azure DevOps
Scanner command used when applicable (private details masked)
First of all I would like to emphasis that the new code period configuration has no effect on PR analysis or Short Lived Branches (SLB). On a PR or SLB the new code is all the code that’s introduced in the PR/SLB whether it was yesterday or several days ago. Setting your new code period to 1 day has no effect on PR/SLB, it only has effect on Long Lived Branches.
Now you mention that issues may be raised on old code (not taking into account the new code period). There are a certain number of corner cases where this can happen, for instance a change in the new code can create an issue in old code even if that code was not modified.
Could you send me a screenshot of an issue that you think is erroneously reported as a new issue ? Please provide a full screen screenshot of the issue with all the project and branch details from the top banner
In my understanding, the modified code in PR is highlighted in yellow, but not for this case. Secondly, this vulnerability is not listed in the Main branch analysis.
Indeed the new code is highlighted with yellow background, but as I explained in my previous post you can have rare corner cases where some issues in old code are raised in a PR.
The screenshot that you provide is too tiny for me to tell if that is one of these corner cases, can you provide a full screen screenshot of the vulnerability so that I can see if that can explain the case.
Also you stated that the issue is not raised on the main branch. Would you confirm that the code of that main branch was analyzed with the same version of SonarQube as the PR (ie there was no SonarQube upgrade in between) ?
