Merge request decorator from GitLab scan task for cfamily project

Hello there,

User versions:

  • Linux 4.18.0-513.11.1.el8_9.x86_64 amd64
  • Java 17.0.9 Private Build (64-bit)
  • SonarScanner 5.0.1.3006
  • Analyzing on SonarQube server 10.4.0.87286

SonarQube is used to scan different projects. The merge request (MR) decorators work fine for .NET projects. The problems are with C projects.

The C projects use Zephyr RTOS and follow “T2 Star Topology” Workspace — Zephyr Project Documentation.

The scanner uses sonar.cfamily.compile-commands. I had to move the project base directory to the workspace root. That allows to scan modules, drivers, etc… The project base (workspace root) is not under version control (application, modules, etc… are).

Normal scans work fine. The goal is to get merge request decorators to work. Based on SonarQube documentation it is possible to configure the sonar properties to detect merge requests.

Added extra properties:

sonar.pullrequest.key=$CI_MERGE_REQUEST_IID
sonar.pullrequest.branch=$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
sonar.pullrequest.base=$CI_MERGE_REQUEST_TARGET_BRANCH_NAME

only for merge requests.

However, the sonnar-scanner fails: ERROR: A pull request analysis cannot have the branch analysis parameter 'sonar.branch.name'

Tried to set the sonar.branch.name= in the properties file, to override the branch name value. Unfortunately, that didn’t work.

What sets the branch name (it is not set in the properties file)? Is there a way to remove it in such cases?

Is the way how I run the scanner is incorrect for used workspace topology or sonar-scanner doesn’t support such cases fully?

Hey there.

When using GitLab CI, you shouldn’t have to specify anything in order for Merge Requests to be analyzed (the scanner should pick up anything related to branch and pull request analysis automatically)

I have a feeling that you might have triggered an analysis on a branch (where CI_COMMIT_REF_NAME is present`), and not a merge request.

Are you sure you’ve triggered the build from a merge request, and not just a one-off scan of a branch?

When using GitLab CI, you shouldn’t have to specify anything in order for Merge Requests to be analyzed (the scanner should pick up anything related to branch and pull request analysis automatically)

Projects do have not an ordinary structure, as mentioned in the comment. We had to disable scm as the scan happens in a workspace directory that is not under git (actual application sources are).

the scanner should pick up anything related to branch and pull request analysis automatically

The idea is to manually fill required MR/PR variables so that sonarqube creates a comment in the correct project, MR/PR about the results.

I have a feeling that you might have triggered an analysis on a branch (where CI_COMMIT_REF_NAME is present`), and not a merge request.

The $CI_COMMIT_REF_NAME is present every time, regardless of the event. “The branch or tag name for which project is built.” Predefined CI/CD variables reference | GitLab. There used to be a bug that didn’t set this variable for MR/PR - CI_COMMIT_REF_NAME have no branch name (#11253) · Issues · GitLab.org / GitLab · GitLab.

What matters is $CI_PIPELINE_SOURCE which must be equal to merge_request_event (the only way by GitLab documentation). It is buggy too, as requires workflow with a related rule to be set. Without the workflow, the variable won’t be set to merge_request_event. An issue exists in the issue tracker…

Are you sure you’ve triggered the build from a merge request, and not just a one-off scan of a branch?

The job runs exactly when MR is detected based on the $CI_PIPELINE_SOURCE.

All required MR/PR variables are present

$CI_MERGE_REQUEST_IID
$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
$CI_MERGE_REQUEST_TARGET_BRANCH_NAME

and propagated to the scan via the sonar-project.properties file. However, the scanner still picks up a branch name and considers it to be a branch scan. Is there a way to disable such automatic behavior?