GitLab Pull Request Decoration is not working

Looks like sonarqube does not get the gitlab URL and I see no way to configure the gitlab URL in sonarqube. At least it’s undocumented.
The result is, that no sonarqube information arrive in gitlab and the mergerequest stays green without any hint about the failed quality gate in sonarqube.

  • versions used:
    • SonarQube Developer Edition 8.1 (build 31237)
    • sonarqube gradle Plugin 2.8
    • gitlab community edition 12.5.5
    • gitlab runner 12.5.0)
  • error observed (more logs attached):
2019.12.19 14:20:03 ERROR ce[AW8eh5gQ2kjqPXwA45Op][c.s.C.D.D.A] Configuration is incomplete: GitlabPrSettings{instanceUrl=null, token='********************', projectId=null, projectUrl=null, prId=7}
  • steps to reproduce
    gradle execution in gitlab pipeline
./gradlew --debug -s sonarqube -Dsonar.host.url=$SONAR_URL -Dsonar.login=$SONAR_LOGIN -Dsonar.pullrequest.key=$CI_MERGE_REQUEST_IID -Dsonar.pullrequest.branch=$CI_COMMIT_REF_NAME -Dsonar.pullrequest.base=$CI_MERGE_REQUEST_TARGET_BRANCH_NAME

all available environment variables can be lookedup in the attached logs from the gitlab pipeline


sonar.logs.txt (12.2 KB)
gitlab.pipeline.debug.log.txt (282.4 KB)

Hi, welcome to the community forum! Gitlab URL (and other variables) are automatically detected by the scanner during the analysis, so there is no need to provide them. Please remove all your -D arguments.

Also, please use then documented env variables for the url and token, as described here : SONAR_TOKEN and SONAR_HOST_URL

1 Like

Ah, I’m running into this too, although I don’t even see any sort of logs about Gitlab anywhere. Did you have to enable any additional logging there?

@pierreguillot thanks, this was the trick, works now fine :smiley:
Maybe this should be explicitly documented because https://docs.sonarqube.org/latest/analysis/pull-request/ said I have to set this 3 properties to enable PR analysis.

@devicenull I enabled debug logging to maybe see the cause: sonar.log.level=DEBUG (I run sonarqube in docker, so just set this as environment var)

I agree that this piece of documentation may be confusing. I created a ticket to improve it. Thanks for the feedback!

My issue was I was using a custom entrypoint script (that was based around the old community gitlab plugin). Once I reverted to the normal one, this started working properly.

I’m glad you figured it out :slight_smile:

Hello,

I get the same problem as @xtermi2:

2020.01.13 10:34:04 ERROR ce[AW-ed7nLktc3_C7Zsz6u][c.s.C.D.D.A] Configuration is incomplete: GitlabPrSettings{instanceUrl=null, token='********************', projectId=null, projectUrl=null, prId=9}

We use SonarQube 8.1 developer edition. I have configure Gitlab ALM in General Settings with a working token.

As far as I understand, it is because only gitlab CI is currently supported and we use jenkins to build our app, am I right @pierreguillot ?
Do I have to wait for this ticket https://jira.sonarsource.com/browse/MMF-1901 or is there a workaround to set missing parameter by settings some environment variables or giving parameters to sonar scanner ?

Yes you are. The workaround would be indeed to provide the expected Gitlab CI environment variable that are expected by the scanner, but i would not advise you to do that, as it his highly likely that we complete MMF-1901 for SQ 8.1, and you would have to change your implementation again in 2 month.

Okay, thanks.

So can I expect the MM-1901 to be live in SQ 8.2 or 8.3 ?
If not, maybe you can list the needed environment variables. Since we used a library for our CI in Jenkins, we can easily configure the things for all of our projects.

Yes, MMF-1901 is a high priority on our side.

Hi,

Sorry for joining a bit late to the discussion.

Could you publish the parameters to get this working?

Though I understand you are planning to implement MM-1901 I can work around this now using a jenkins pipeline library, and would prefer to do so as this is an important feature.

All help much appreciated.

Hi Pierre,

Was MM-1901 included in SQ 8.1? We recently upgraded to SQ 8.1 DE and are still facing this error as others in this post reported:

Configuration is incomplete: GitlabPrSettings{instanceUrl=null, token=’****************’, projectId=null, projectUrl=null, prId=null}

If not, what are the missing parameters we should include until another update is released?

Thanks!

MM-1901 is not in SQ 8.1

Hi Guillaume,

Thanks for the confirmation. Would you know about the “Gitlab CI environment variable” referred to in Pierre’s reply previously?

I don’t mind setting it until SQ 8.2 or 8.3 handles this properly.

Thanks!

@pierreguillot now that’s sonar 8.2 is released I try to use the new feature and it works \o, thanks.

But I have one more question, can we configure “Configuration Name” and “ProjectId” using system property that we give to the sonar scanner instead of configuring each project ?
That will allow us to do nothing for new project an for existing project

I’m watching this thread for several months. I have same question as @guillomep.

Is it possible to set “Configuration Name” and “ProjectId” using environment variables or scanner parameters? It would help us to automate process of creating and configuring projects without manual steps :slight_smile:

I assume it is possible since GitLab CI does it.

Yup that was discussed during the implementation, and we decided to not go with it. The idea is that we want to avoid the scanner to be able to define configuration that require admin privilege on the project. That’s the kind of “auto-magic” feature SQ try to avoid. I personally think that auto-discovery and auto configuration would be really useful. I pinged our dear SQ PM @Chris to discuss this.

2 Likes

One way of automating this configuration would be sonar api call:

curl 'https://sonar.acme.com/sonar/api/alm_settings/set_gitlab_binding' \
  --data-raw 'almSetting=sonar-decorating-pull-requests&project=com.acme.example%3Alogin-service&repository=10'

It’s a shame that it requires admin role though.

1 Like

Hi there, I didn’t want to create another thread since I think my issue is relevant to this one.

I’m using Jenkins with SonarQube 8.1 Community Edition, and cannot get the PR decoration work in Gitlab. Reading through this, I understand that it works auto-magically from GitlabCI because it can detect/read the different environment vars provided by GitlabCI (described here).

Unfortunately, I am not able to update SQ because of plugin compatibility, but am still trying to get Jenkins to decorate the relevant MR/PR in Gitlab (on-prem). Is it possible to get sonar-scanner to run from Jenkins, but think it’s running from GitlabCI with the presence of the environment variables it normally expects from GitlabCI? If so, could someone tell me which specific variables need to exist?

I tried to use @kszpakowski’s API call, but when I used the following URL:

https://<sonar-host>/api/alm_settings/set_gitlab_binding?almSetting=sonar-decorating-pull-requests&project=<project>:login-service&repository=<project_id>

Where sonar-host is the URL of our internally hosted SQ 8.1 instance, project is the name of the project in SQ, and project_id is the project_id of the repo in Gitlab.

Unfortunately, even when logged in as admin, that API call returns the following error:

{“errors”:[{“msg”:“Component key ‘project:login-service’ not found”}]}

I appreciate any assistance in advance.