Understanding SCM Sensor in GitLab Merge Request (Pull Request)

[MichaelGissing]

Issue

I am currently investigating GitLab CI behavior for one of our engineering teams.

I think I found the issue of “Sonar does not detect which files have changed in the merge request!!” - the SCM sensor was disabled for the project in general settings.

However, this led me to ask myself: which features are affected by this setting? So I would be happy if you could help me clarify a few things.

Note: At the moment we are using an older version of the sonar gradle plugin, but I’d like to hear a general answer on how it’s supposed to be with sonar. We will update the plugin eventually anyways.

Questions

• If sonar.scm.disabled=true is set, then the sonar scanner can’t identify which files changed in a merge request, right?
  • Which files does the analysis take into account then for the quality gate? Does it take all the files from the branch and compares it to the latest analysis of the main branch?
  • I have observed that it’s not just adding unrelated files to the “new code” for the merge request, but also not showing files that were definitely changed in the MR. So I suppose the MR analysis is just unreliable with sonar.scm.disabled=true?
• The SCM feature takes care of two things, detecting changed files in an MR and “blaming” people based on git blame, correct?
• We only do shallow clones of our bigger projects to save time and transfer volume.
  • As long as SCM is enabled and both the latest commit of the target branch and the source branch are available, Sonar can still figure out the changed files for a MR, correct?
  • What’s Sonar’s general perspective on shallow clones? What do we miss out on if we don’t do a full clone of the whole repo?
• While analyzing our team’s CI, I noticed that GitLab CI checks out the repo with a detached HEAD for the MR. There are no git refs available at all. How does sonar detect the changes anyways? Is the scanner using the GitLab CI env variables like CI_MERGE_REQUEST_SOURCE_BRANCH_NAME, CI_MERGE_REQUEST_TARGET_BRANCH_NAME, and CI_MERGE_REQUEST_DIFF_BASE_SHA?

Environment

• Java
• GitLab.com hosted code (SaaS)
• Sonar scan in GitLab CI using the gradle plugin
• Gradle plugin 3.4.0.2513 (outdated)
• Sonarcloud (paid, private projects) as target
• ALM linked

[ganncamp (G Ann Campbell)]

Hi,

@MichaelGissing

If sonar.scm.disabled=true is set, then the sonar scanner can’t identify which files changed in a merge request, right?

Right

@MichaelGissing

So I suppose the MR analysis is just unreliable with sonar.scm.disabled=true?

Yes. Without SCM data, analysis can’t determine what was and was not part of the MR. (Could you? )

@MichaelGissing

The SCM feature takes care of two things, detecting changed files in an MR and “blaming” people based on git blame, correct?

I’d broaden it slightly to new code detection in any kind of analysis, but yes.

@MichaelGissing

What’s Sonar’s general perspective on shallow clones?

Don’t do it. Analysis needs all the SCM data to accurately detect what’s new and what’s not. Shallow clones will get you bad results.

@MichaelGissing

I noticed that GitLab CI checks out the repo with a detached HEAD for the MR. There are no git refs available at all.

Ehm… That’s not great. I’m fuzzy on the exact details, but search this community for “detached head” and all you’ll find is messages from people having problems.

In short: analysis needs full & accurate blame data or you’ll get poor detection of what’s “new”.

 
HTH,
Ann

[MichaelGissing]

Thanks @ganncamp for clarifying!

Regarding the GitLab CI MR pipelines, I found this post by your colleague in the meantime:

Pull Request Analysis in GitLab without using detached pipeline ("only: merge_requests")

Hi, SonarQube reads a bunch of “only: merge_requests” specific environment variables: CI_MERGE_REQUEST_IID (Mandatory to trigger a MR decoration) CI_MERGE_REQUEST_SOURCE_BRANCH_NAME (Mandatory to trigger a MR decoration) CI_MERGE_REQUEST_TARGET_BRANCH_NAME (Optional, will use the main branch as default) CI_MERGE_REQUEST_PROJECT_URL (Required to have the link to the MR from SQ PR view) (+ others environment variable not specific to only: merge_requests) Keep in mind that its internal implemen…

So I guess it does an auto-detection based on the environment and is not irritated by the detached head.

So all should be fine for us, thanks for your assistance.