GitLab integration as external status check instead of failing the ci pipeline

We are migrating from Bitbucket to GitLab Ultimate

The current GitLab integration of SonarQube is as follow:

See docs: GitLab integration

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.

Hey there.

I’ve moved your post to the right category for somebody to take a look. Thanks for calling out the External status checks (I didn’t know about them!)

So we have open-source a small webhook-receiver that does exactly this:

It puts the quality-gate status as external status check on GitLab (Ultimate):

Source: GitHub - unblu/u-sonar-status: SonarQube Quality Gate Status as External Status Check in GitLab Ultimate

It works quite well, but we have one problem when we retrieve the quality gate status:
api/project_pull_requests/list does not contains the commit sha (I can’t comment on the old thread)

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.

Hi, there!

I would like to join this petition because, precisely, our clients need to get their pipelines working even if the quality gates are failing.

This would be a useful feature for SonarQube.

One of our clients report they would be useful for them to get the decoration reported as a thread and not as a message, therefore allowing them to approve the MR even if its failing. The responsibility is then, on the reviewer’s side of the merge.

MicrosoftTeams-image (2)

Thank you!