Sonar-scanner pull request analysis is unable to identify new code in pull request

Hi there,

I’m having issues with pull request support in sonarqube server.
Consider the following scenario

  1. I have branch base with a file A.java with the following contents
class A {
    public static void main(String[] args) {
        String a = "a";
    }
}

And commit these changes.
2. I perform a sonar branch analysis of base which leads to the sonarqube server showing the contents of this file.
3. I create a new branch feature from base and modify the contents of A.java

class A {
    public static void main(String[] args) {
        String a = "a";
        String b = "b";
    }
}

And commit these changes
4. I go back to base and modify the contents of A.java to

class A {
    public static void main(String[] args) {
        String a = "a";
    }


    public void newFunc() {
        String q = "a";
    }
}

And commit these changes.
I do not run branch analysis of the code at this point.

  1. I switch to feature branch and merge with base so that A.java is now
class A {
    public static void main(String[] args) {
        String a = "a";
        String b = "b";
    }


    public void newFunc() {
        String q = "a";
    }
}

6.I now run pull request analysis for feature specifying the pull request parameters -Dsonar.pullrequest.key=1000 -Dsonar.pullrequest.branch=feature -Dsonar.pullrequest.base=base

In the pull request analysis , I see that both String b = "b"; and newFunc() are considered as new code for this branch , However my expectation is that only String b = "b"; shoudl be considered as new code.

On adding verbose logs, I noticed some of these logs

SCM Step is disabled by configuration
SCM information about changed files in the branch is not available
SCM Publisher is disabled

Checking the source on github for this, I noticed that this error comes up if the ScmProvider is null which happens due SCM being disabled here.

I was wondering what could cause this?
Based on the thread at Pull request diffs show unrelated lines on older PRs. Diff not against merge base? , my expectation is that the sonar scanner would be able to identify the diff in this pull request config and only show the changes on this branch as new code.

PS: This problem does not occur if I run branch analysis at step 4 which is expected.

Also adding my version details:
Sonar Server: Enterprise 9.9.0.65466
Sonar-gradle-plugin: 5.1.0.4882

Hi again,
It looks like the sonar.scm.disabled flag also controls the SCM based code change detection according the documentation at SCM integration

Is this expected? I was wondering if there is a mechanism for me to modify this property while making the analysis request before I request this config to be updated on our installation of sonar server.

A follow up to this if I could enable only a subset of the scm features. i.e. I would want the support SCM based new code detection. However not have the support for blame and issue assignment.

Hi yet again,
So I did finally manage to get this work using -Dsonar.scm.disabled=False. However is there a way of decoupling the blame features from the “new code analysis” feature set?

Hi,

Welcome to the community!

Your version is past EOL. You should upgrade to either the latest version or the current LTA (long-term active version) at your earliest convenience. Your upgrade path is:

9.9.0 → 2025.1

You may find these resources helpful:

If you have questions about upgrading, feel free to open a new thread for that here.

Regarding your question: no. SCM data is required to identify new code.

And global admins have the ability to do this at the instance level:

Administration → General.

 
HTH,
Ann

Hi Ann,

Thank you for the information. Can you also help me understand what would happen if “Disable developer aggregated information” is disabled?
Would scm data not be used to determine the changes in the branch?

Based on the documents, I see the workaround mentioned as

Without SCM data, SonarQube determines new code using analysis dates (to timestamp modification of lines).

My understanding of this is that the new code is determined based on comparing with the latest branch analysis done for the target branch. I’m not sure what is the meaning of “to timestamp modification of lines”

On the upgrade , thanks for sharing the documentation for this. I will take this up with our team.

Hi,

It does just what’s shown in the screenshot:

Don’t show issue facets aggregating information per developer

So, a couple search facets disappear from the Issues page.

This is not appropriate for PR analysis. It’s a workaround that was developed for situations where SCM metadata is truly not available and PRs are highly unlikely to be used, much less analyzed. E.G. COBOL.

 
HTH,
Ann

Hi,

Rephrasing my question on this.

  1. Will I continue seeing git blame information on the sonarqube server
  2. Will the sonar-scanner still collect git blame data?
  3. Will disabling this also override me setting sonar.scm.disabled=False via the scanner invocation

Hi,

Yes.

Yes.

No. Disabling SCM detection during analysis means the data isn’t read by analysis and cannot be used for any purpose.

Disabling search facets is entirely unrelated to that.

 
Ann

Hi Ann,

Thank you this helps. Can you also guide me to the documentation for the functionality you shared? I wanted to understand more on the features it provides and disables.

Hi,

There is no further documentation beyond what I’ve shared with you. The toggle removes certain search facets from the Issues page. That’s all.

The underlying data is still there. You just can’t filter by it from the UI.

 
HTH,
Ann

Hi,
Thank you for the details.