On the Merge Request a comment is added by SonarQube with the link to jump from the MR to the analysis. This contains a badge telling if the Quality Gate was successful or not.
The recommendation to prevent merge of MRs containing failing quality gate is to fail the corresponding pipeline.
However, we often have this workflow:
A quality gate is failing for a change
Some findings are marked as “won’t fixed” directly in SonarQube
The quality gate is green again.
With the current proposed integration, this means we have to rebuild the pipeline.
For GitLab Ultimate users, it seems that External status checks is a better way to bloc a MR based on a status computed in an external tool.
When something has changed on SonarQube, the corresponding external status check can be updated without having to re-run the CI pipeline.
This would be closer to the integration we had with Bitbucket.
But given a projectKey and a pullrequest we would like to get:
The quality Gate Status
The revision (the value sonar.scm.revision) where the scanner did run.
We have tried following:
/api/qualitygates/project_status?projectKey=<key>&pullRequest=<pr> does not contains the revision information
/api/project_pull_requests/list?project=<key> contains the information on SonarCloud but not on an on-prem SonarQube server (tested with 9.9)
Even with multiple Web-API call to Sonar, I do not understand how I can access the revision information.
For the flow where the tool respond to a Sonar Webhook Event there is no problem the information is present in the event.
But there is an additional where GitLab request to know the status (this is the “Retry” button on the external status check). In this case the u-sonar-status tool is contacting Sonar to know what is the quality gate status. IMO not checking if the head of the MR matches the sonar revision is a mistake since as soon as you push a commit to the MR, GitLab will request the status to be updated and you can not set the status based on an outdated scan in Sonar.
