Sorry if this question was already asked or if its answered in a tutorial/FAQ but I couldn’t find it
Our Pull Request analysis is systematically bringing up issues about methods not modified in a file that was modified (another method was added/modified)
Is there a way to disable that so that only new code is analyzed ?
We know we have a lot of technical debt to pay but we don’t want to bring it up to every developer at every pull request, as long as they don’t add up new debt.
I am not sure what you mean by SCM but if it is Source Control, we are using git, our repository is hosted on Azure Devops servers
Are you sure the value of sonar.pullrequest.base is correct?
No I am not, it should be master, I don’t see anywhere in our build pipeline the parameter being overriden, how can I check it is using master during analysis ?
It seems to be master
If you browse the Code tab of the pull request on SonarCloud, do you see only the files modified by the pull request?
Yes
And in each file, do you see a yellow background for the modified lines (as opposed to white for unmodified lines)
Yes by SCM I meant source control, so Git, thanks.
As for sonar.pullrequest.base, based on your responses about the Code tab, your setting must be correct. Unless there’s a misunderstanding. It would be good to find where this is set in your pull request analyses, because I don’t think we have a way to detect automatically, it must be specified somewhere, and it’s a key piece of information.
I will ask you in a private thread about an example of an issue that should not be raised on the PR.
Thanks @janos for private reply!
For anyone else having same issues in future:
The PRs were being compared against a much older Sonar-scanned version of the master branch.
I’ve now done a fresh scan of the master branch, and re-ran the PR scans to get the correct results.
Huge kudos to you @Johan-v-r ! I didn’t actually know this was going to be the answer, it was quite a mystery to me, I’m glad you figured it out so now I know!
To further clarify, the problem was that the base branch (into which you want to merge the PR) had some new commits that have not been analyzed in the base branch, and issues in those commits were showing up in the analysis of the PR, even though they were not actually introduced by the changes in the PR itself. To avoid this problem, all you need to do is make sure that when new commits are pushed to the base branch, analyze it again.