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 
)
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! 
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:
Build:
image: $MAVEN_IMAGE
stage: compile, test and quality
script:
- 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 Gitlab.com 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!
