Issues on pull requests about old code

  • ALM used - Azure DevOps
  • CI system used - Azure DevOps
  • Languages of the repository - C#

Hi,

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.

Thanks,

3 Likes

Hi Paul,

This could happen when the new code lines are not correctly detected, typically by misconfiguration.

  • What is the SCM of the project?
  • Are you sure the value of sonar.pullrequest.base is correct?
  • If you browse the Code tab of the pull request on SonarCloud, do you see only the files modified by the pull request?
    • And in each file, do you see a yellow background for the modified lines (as opposed to white for unmodified lines)

Hi Janos,

Thanks for your reply.

  • What is the SCM of the project?

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 ?
image
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)

Only for the modified 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.

Hi - I’m sitting with exactly the same issue, and the exact same environment (git, master in DevOps)

Have you found a solution to this issue?

@janos Can you please get in touch regarding this issue, it’s becoming a massive pain.

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.

3 Likes

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.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.