SonarQube - Analyse Pull Request - Changed Files Only

SonarQube Server / Community Build
,
1
  • Using SonarQube and Scanner
  • what are you trying to achieve?
    Trying to analyse GIT Pull request - Only changed files
  • what have you tried so far to achieve this
    sonar.sources=.
    sonar.pullrequest.branch=
    sonar.pullrequest.key=

Problem: It analyses the whole repo instead of just analyzing the changed files. How to analyze only the changed files?

2

Hi,

Pull request analysis does analyse the whole repo. There’s currently no way to turn that off.

 
Ann

3

But… why? When I run an PR analysis, I don’t care about issues in files that I didn’t touch. I only care about the issues that are actually in files changed in that PR.

4

We do not currently support incremental analysis as it can result in less accurate scanning results. This has come up quite regularly, especially in the context of branches and pull requests, and internally there is a lot of discussion around this, but I don’t think we have anything to share at this time.

5

But sometimes I do see incremental results about only the changes in my branch, and sometimes I get the full set of errors across the entire repo. Do you happen to know why that would be? Having this weirdly inconsistent behavior seems worse than either option.

6

Hi,

You should open another thread for this:

Analysis covers the entire repo, but reporting should not.

 
Ann

7

I opened PR Analysis Results Inconsistent - results from master branch sometimes included a few days ago, but haven’t gotten any response.

1 Like
8

I couldn’t agree more with Melissa. I hope you decide to introduce incremental analysis.

As a new (and willing to pay) user of SonarCloud, I have to onboard my existing code repositories. Some of these repositories host vast code bases and some are legacy. If I were to implement SonarCloud today, it would report on the enormous amount of bugs, vulnerabilities, and code smells per PR. In fact, there would be so many of these historical issues, that it would be impossible to identify any new issues. This effectively renders SonarCloud useless and provides no benefit to my organization.

Is there a recommended way to solve this? Going back and fixing historical issues is simply not an option.

9

Hi @HubertChen-OM,

To my mind, your post really presents two different issues:

  1. It takes a long time to analyze your entire code base
  2. It’s not feasible to fix old issues, you only want to see the new ones

For right now, I can’t help you with #1, but for #2, that’s exactly why we introduced the New Code period / Leak Metaphor, and the Clean as You Code methodology. Basically, the idea here is that SonarQube helps you focus on the changes in new code to make sure that the new changes going into production are clean.

 
HTH,
Ann