I have pipelines set up in Gitlab CI that are running sonarscanner with -Dsonar.pullrequest.key=<#> -Dsonar.pullrequest.branch=<branch-name> -Dsonar.pullrequest.base=master. I realize that this is meant to happen automatically if you’re running Gitlab CI sonarscanner for MR-type pipelines, but I’m trying to do this for branch-type.
I can see the values being correctly filled out as arguments when I start the scan, but when I view logs for branch-type scans, the final URL is logged as a branch URL and the view in the project on Sonarqube is a branch view, not a PR view. In comparison, on an MR-type pipeline, the final URL is logged as a pull request URL and the view in the project on Sonarqube is the pull request view.
Checking the verbose logs of the two scans (branch, and MR) shows that Sonarqube is identifying the pull request in the MR type, but ignoring the pull request in the branch type, even though the scan is kicked off with the correct analysis parameters present.
The wiki for PR decoration says “Manually setting Pull Request parameters overrides automatic detection.” so I am confused why these are not being set as PRs during scan if the values are present.
We are looking to do PR analysis on branch-type pipelines because some of our users prefer not to use MR pipelines. However, in cases where we identify a single associated open MR for the branch, we can interpolate the correct values to send to sonar for a PR scan in the branch pipeline.
Per the documentation, I was assuming providing these values would override any auto-scanning Sonarscanner is already doing. I’ve been trying to find the right combination of variables the scanner is using to identify the pipeline type and force the issue, but I haven’t managed it yet. I also wasn’t able to find details in the source code.
Branch/PR analysis is only supported in Developer Edition and higher. We won’t be able to provide any support through in this community for Branch/PR analysis on Community Edition.
The PR analysis is working as expected on my MR-type pipelines for this version of scanner & SQ.
I have some users doing MR-type pipelines, and some doing branch.
I’m not clear why the Community Edition would mean that sending the same parameters to scanner in both scenarios would cause different results.
Is it just that we have to upgrade in order to use this override? Is there no way to force the scanner to just use the parameters we’re providing directly? We have configured the scan to send all the necessary data, regardless of pipeline type. We just need it to actually use it, and not ignore it.
I find that if I ensure GITLAB_CI=false is set in the environment before the scanner runs, it works exactly as I want it to in a branch-type pipeline with the pullrequest fields set as before.
While I can make this change so my users have the decoration as expected, whether for branch-type or MR-type Gitlab CI pipelines, I would like to know if there is a better solution.