Greetings! I’m having some troubles using the PR decoration with Gitlab. I’m using Sonarqube Server 8.4.2. The PR decoration works perfect, but the total code coverage is displayed wrong since there is an external job triggered that is adding 0.0% coverage, and affecting the total coverage.
Is there any way to avoid the triggering of this external job with the SQ link on the detached pipeline?
Thanks in advance for any information you can give me. Please let me know if I have to add more information about this.
As it seen on the images, when I run the job “sonarqube_scan_mr” on a detached pipeline (with the condition for only on merge requests on GitLab), after it finish, a second step appears automatically on “external” stage, called “Sonarqube” and it points to the sonarqube URL for the MR scan. Since automatic step is giving 0,0% coverage, so the total coverage media is being affected: (95 + 0)/2 = 47,5
Is there any way to avoid this second step to be triggered? I’m using the GitLab integration that comes with the Sonarqube 8.4.2.
I’m not familiar with the GL interface, so I’m not certain I understand what I’m seeing in your screenshot. I guess this is 2 separate analyses, one of which reports correct coverage numbers back to GL and the other of which does not? And then for some reason GL averages the values.
If that’s correct, there are a couple things here, neither of which directly relates to SonarQube IMO:
where is that 2nd analysis coming from and how can you turn it off? (a GL question)
why isn’t that 2nd job configured to report coverage? (Okay, this is an analysis configuration job, so kinda related to SonarQube but it goes away if you fix the first one).
Just for clarity part of my confusion stemmed from the fact that you cannot “update” an analysis, only replace it. So in SonarQube there is no average of coverage across 2 jobs. First you have 95% and then that’s replaced by 0% from the next analysis.
The 2nd step on the pipeline is appearing automatically. I’m not defining it in any part of my pipeline configuration. As I understand, that step is created by the Sonarqube-Gitlab integration itself, so I can’t control it in any way.
Ok, thank you for helping me with this. If there is any need for contacting anyone by call or email, I’m available for that. Also, please let me know if there is any more information needed from my side for this.
I have same problem. I want sonar analysis to be part of my pipeline, but don’t want it to block merge the merge request. I setup the first job to not block merge but the second (automatically added) job I have no control of, and therefore cannot set it up to not block merge.
Any advice how to remove the second job?
