merge request decoration

Great, thanks for the info.

I suggest removing the sonar.projectKey properties from the submodules and to add <sonar.moduleKey>${project.groupId}:${project.artifactId}</sonar.moduleKey>
to the parent pom.

I created a sample project with multiple maven modules on GitLab that correctly sends merge request decoration:

Do you see anything that could be different for your project?

Hello @TomVanBraband

Thanks for your help.
As asked, I removed all the properties related to sonar in my submodules and have just those in the reactor:

I relaunched my pipeline but I still do not have any PR decoration.
For information, now that I re-imported the project again in SC the SONAR_TOKEN changed. I changed it also in my CI to be sure that it won’t be the blocker but it still not work anyway…

I had a look at your project and it seems to me that we have kind of the same configuration…

Because all of this changes, should I close the current MR and reopen a new one ?
Should I re-import the project in SC (I would avoid if possible :stuck_out_tongue: )

Another question, my analysis on my testing branch has 0 issue and 100% of code coverage on the new code. Can it explain that if there is no issue, there is no PR decoration ?

Thanks again for your help, I am sur we will make it!

Agreed @gbrissonnette, we’ll get there! :smile:

We can rule a maven configuration error then. Could you provide the ID of a background task that failed using your updated maven configuration? You can see this under Administration > Background Tasks

Tanks @TomVanBraband I would but I do not have any failed background task:

But still no PR decoration

Thank you that’s helpful!

The issue is that the scanner does not recognize it’s scanning a PR. It only recognizes that it’s scanning a branch that is not the default branch (for example /feature/sonar-cleanup).

The scanner automatically reads the environment variables that are set by GitLab to link to the correct merge request. (This means that you don’t have to set the sonar.pullrequest.key, sonar.pullrequest.branch and sonar.pullrequest.base properties yourself).

However if the scanner does find some manual configuration it does not try to automatically configure the parameters. We can check that this is the case by examining the debug logs.

Could add a -X parameter to your mvn verify sonar:sonar command to enable the debug logs?
If the scanner found some manual configuration it will log the following line:

Found manual configuration of branch/PR analysis. Skipping automatic configuration.

Is that line present in your debug logs?

Hello @TomVanBraband

Sorry for the late answer.

I ran the job like this:

  image: $MAVEN_IMAGE
  stage: compile, test and quality
    - mvn verify $MAVEN_CLI_OPTS $MAVEN_OPTS
    - mvn sonar:sonar $MAVEN_CLI_OPTS -X $MAVEN_OPTS
  <<: *maven_cache
  <<: *artifacts

I had to split the instructions in 2 or else I had to many logs and said that there were to many logs to be displayed.

I searched for this line in the logs but wasn’t able to find any about manual configuration

I attach here the logs in DEBUG mode (let me know when you’ve got that file so I delete it here)
job.txt (1.1 MB)

Hello @gbrissonnette,

Thank you, I’ve received it!

The interesting log line is the following:
Auto-configuring branch feature/sonar-cleanup.

This means that the following environment variables


are not available in the build. These should automatically be exposed by Gitlab when a build is ran for a merge request. Since this is not the case you are probably missing something in your .gitlab-ci.yml configuration. Could you try the configurations described here?


Thanks a lot, we got it !

Yes, the issue was that the job we configured was without any rule or only that specifies to be run on Merge Request. As you explained, that means that we do not have the context that your scanner expect.

I just added the merge request in a dedicated only configuration and it works out of the box!

Thanks for the help!

1 Like

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