How does sonar scm analysis work?

SonarQube Server / Community Build
, , ,
1

Hi there,

I’m using sonar-scanner cli 7.2.0.5079. This is being used to analyze Gitlab merge requests on CI with merged result pipelines enabled. For example; Merged results pipelines | GitLab Docs. We’ve noticed that the SCM analysis often identifies the incorrect merge-base in this setup. This also changes on subsequent retries of the same pipeline.

I came across No merge base found between HEAD and refs/heads/master for PR analysis - #2 by ganncamp which talks about the merged result pipelines being a probable cause for it. But does not go into much detail.

Can someone help me understand the root cause of this. And what can be ways to solve this.

2

Hi again,

So looks like SonarCloud finds files that are not related to a Pull Requests as "new code" - #32 by Michael_Carter was a solution that worked for us too.

I’m still looking to understand

  1. Why does sonar-scanner prefer refs/heads/development over refs/remotes/origin/development . In a CI environment, the local reference for a branch would always be stale unless that is explcitiyl checked out.
  2. What impact could the gitlab merge commit have on finding the correct merge base.
3

Hi,

Analysis works from the SCM metadata in the analysis environment. refs/remotes/origin/development is not in the local environment, so it’s not available to analysis.

Analysis works on the code in the local environment. If there are changes subsequent to checkout, then you’re not analyzing what you think you are.

 
HTH,
Ann

4

Hi Ann,

Thank you for the details. Could there also be issues due to using a temporary commit that merges the source and target branches to verify issues. ?

For example the Merged results pipelines | GitLab Docs pipelines

5

Hi,

Yes, absolutely. Don’t do a merge commit before analysis. I’ve forgotten the details, but it will screw things up.

 
Ann

6

Hi Ann,

Is there any chance you can also provide the details for this? I’m happy to refer any documentation/code that talks about this too.

We depend on merged pipelines since that helps us avoid a lot nasty scenarios that would come up in case we were to merge based on individual branch builds and tests and I wanted to understand why the opposite would be true for running sonar analysis.

Thanks

7

Hi,

I don’t have the details readily to hand. I can put this in queue for someone who might, but it may be a long wait.

In the meantime, I urge you to consider running analysis before your merge commit.

 
Ann