Pull Request Decoration not working with gitlab

Version Information:

SonarQube Scanner 4.2.0.1873
Java 12.0.2 Oracle Corporation (64-bit)
Mac OS X 10.15.7 x86_64
SonarQube server 8.4.1
gitlab server satisfies 13.7.4

Following this documentation: https://docs.sonarqube.org/8.4/analysis/pr-decoration/

Pull Request decoration via gitlab does not appear to be working for us. It is a self managed server.

The Admin->Configuration->ALM Integrations indicates the feature is enabled.
No errors seem to be output when the scan runs and projects are successfully analysed in our GitLab CI pipelines.

The project configuration looks correct, the configuration name is set and the project ID is empty.

I don’t see anything relevant in the sonarqube logs. I also don’t see any overt indication that any decoration is being attempted.

We have already tried:
https://jira.sonarsource.com/browse/SONAR-13290

Any other suggestions to help us get this working or at least where to look for relevant error logs?

One thing that is not clear to me is whether I need to pass these into the scanner:

  • sonar.pullrequest.base
  • sonar.pullrequest.key
  • sonar.pullrequest.branch

Is that done automatically now or should I be specifying these? This thread implies it is automatic from 8.3 onwards but I wasn’t clear if we are inadvertently doing Branch Analysis as opposed to Pull Request Analysis:

I got around this by specifying the following params in a sonar-project.properties file:
sonar.pullrequest.key=
sonar.pullrequest.branch=
sonar.pullrequest.base=

I also had to specify gitlab projectID on the Project config in Sonarqube . The docs implies some of this is handled automatically, however, that only appears to be true for certain configurations.

Hi @Glen,

You shouldn’t pass those three parameters via the sonar-project.properties file. If you do that, no matter the Merge Request you create on GitLab, you will need to update those values each time. This is highly inconvenient and error prone.

What is the CI you use? Is it also GitLab? If it is, those parameters are handled automatically. If you use GitLab CI, what is your .gitlab-ci.yml file looking like?

About the Project ID, as specified on the docs:

Setting your project settings

Go to Project Settings > General Settings > Pull Request Decoration and select your Configuration name. If you’re using GitLab CI, you can leave Project ID blank, as it will be auto-detected. If you’re using a different CI tool (e.g.: Jenkins, Travis CI, etc), or run the analysis manually, provide the project’s numerical ID.

Cheers,
Daniel

Hi Daniel,

It is Gitlab and .gitlab-ci.yml.

I think some of the other args we specified mean’t the pull request analysis does not happen unless I force it. We wrap sonar-scanner to get Xcode coverage reporting correctly but maybe you know if specifying any of these would prevent PR decoration?
sonar.projectVersion
sonar.gitlab.commit_sha
sonar.gitlab.ref_name
sonar.gitlab.project_id

We had these set from when we used a third party plugin for gitlab auth which got deprecated around 8.x. I should probably try it without these being set.

We don’t have to hardcode the values, our stage currently looks like this:

sonarqube_mr_decoration:
  stage: Sonarqube MR Decoration
  script:
    - xcodebuild clean test -workspace "$WORKSPACE" -scheme OurUnitTestScheme -destination platform=iOS Simulator,name=iPhone 8,OS=latest -configuration Debug -enableCodeCoverage YES -derivedDataPath Build -json
    - echo $CI_MERGE_REQUEST_IID
    - echo $CI_MERGE_REQUEST_BRANCH_NAME
    - echo $CI_PROJECT_ID
    - sonarqube-ios -p $PODSPEC -k $CI_MERGE_REQUEST_IID -b "$CI_MERGE_REQUEST_BRANCH_NAME" --project-id $CI_PROJECT_ID --debug
  only:
    - merge_requests
  tags:
    - ios

-p corresponds to -Dsonar.projectVersion
-k corresponds to -Dsonar.pullrequest.key= $CI_MERGE_REQUEST_IID
-b corresponds to -Dsonar.pullrequest.branch=$CI_MERGE_REQUEST_BRANCH_NAME
-Dsonar.pullrequest.base=dev is fine for us to hardcode.

Gitlab provides these variables if only: merge_requests is used. This isn’t ideal because it results in a detached gitlab pipeline. I’m still trying to get the auto detection working since it would be way more convenient.

I’ll post back if removing the mentioned parameters does enable the auto detect to work.

Cheers!
Glen

A further test shows one of those parameters is preventing the analysis. I believe it is now auto-detecting everything. I wish I’d tried that first :slightly_smiling_face:. For anyone else look at this my stage now looks like:

sonarqube_mr_decoration:
  stage: Sonarqube MR Decoration
  script:
    - xcodebuild clean test -workspace "$WORKSPACE" -scheme OurUnitTestScheme -destination platform=iOS Simulator,name=iPhone 8,OS=latest -configuration Debug -enableCodeCoverage YES -derivedDataPath Build -json
    - sonar-scanner -Dsonar.qualitygate.wait=true
  only:
    - merge_requests
  tags:
    - ios

Happy to see you could make it work and simplify your gitlab-ci.yml file at the same time!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.