Template for a good new topic, formatted with Markdown:
ALM used (Bitbucket Cloud, Azure DevOps)
CI system used (Azure DevOps)
Scanner command used when applicable (Uses Azure DevOps Sonar Cloud plugins)
Languages of the repository (C#, .Net Core, React / Angular, Python)
Error observed (“Code Coverage on New Code not reflecting accurately. Analysis results show metrics for the entire codebase rather than focusing on newly added code.”)
Steps to reproduce (“We operate multiple branches and numerous Pull Requests on Bitbucket, utilizing Sonar Cloud for Static Code Analysis. Our primary concern is that when running code analysis, the tool does not provide code coverage data specifically for newly added code lines. Instead, it aggregates data from the entire codebase.”)
Potential workaround (we kindly request a telephonic or virtual meeting to walk us through the expected behavior of Sonar Cloud in our scenario. Your insights and guidance will be instrumental in helping us configure Sonar Cloud to meet our specific requirements.)
Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!
Well, there we go. SonarCloud has failed to detect SCM data, which is required to correctly detect new code. That’s the problem that needs to get fixed.
What tool are you using to build your code? Bitbucket pipelines? If so, can you share your bitbucket-pipelines.yml configuration?
Thank you for your patience. Colin flagged the post for expert attention, and sadly this thread got a bit lost in the process.
Since the .git directory is present on the logs you sent, another frequent cause of this issue is the clone depth.
If the source code is cloned from Git as a Shallow clone (clone depth 0, meaning there is no history) then our engine is not able to properly detect the New Code. It considers the whole codebase as new, leading to what you observe.
Could you check the cloning configuration on your Azure pipeline, and make sure the whole history is cloned?
I’m not an Azure expert at all, I suspect this documentation could be useful: Options for Git repositories - Azure Pipelines | Microsoft Learn
We are conscious it can slow down the clone operation if the repository is huge. To reduce the impact, instead of cloning the whole history and depending on what your development workflow looks like, you can limit it to the latest N commits. N should be big enough to make sure the history contains the commit from which the pull request branch was created on the base branch.
We are not using shallow clone option in our pipelines. Please refer to the below screenshot
Additionally, our repos are not large and those are medium in size