Hi Colin,
Thank you for your feedback.
My use case is the same as the one in the original post almost 3 years ago.
The GitLab integration proposal is not as smooth as the Bitbucket one.
To prevent merging of Merge-Request with failing Sonar Quality Gate for a given Pull Request, the recommended strategy is to fail the GitLab pipeline and then to have a GitLab rule that prevents merging with failing pipeline.
We often have the case of some findings being marked as false positive in the SonarQube server.
In that case the gate is turned to green.
This is reflected in the GitLab, the comment is updated:
But the corresponding pipeline stays red. So we would have to re-run it. This is a problem for our setup.
So we came up with our small tool that reports the Sonar Quality Gate as external status check on GitLab (Ultimate): u-sonar-status
This tool reacts on Sonar Webhook Event where the revision value is present (aka sonar.scm.revision). We can match the revision against the head commit of the source branch of the MR. This works great.
But there is a second flow: we also need to react on a GitLab event, when GitLab asks for the status for a given commit on a MR. In that case you should check the quality-gate in Sonar. But to be accurate you need the sonar.scm.revision value. The GitLab event is emitted especially when there are a new commit added to the MR.
So checking the status of a given Pull Request in SonarQube without the revision will be wrong in most of the case.
I hope SonarQube will be aligned with SonarCloud soon.