SonarQube/GitLab Integration: Set merge request approval

[treichl (Timo Reichl)]

Hello,

is there a way to make SonarQube be part of GitLab merge request approvals? If the SonarQube analysis reports a PASS, it should add an approval via GitLab API. On the other hand, if the quality gate reports a FAIL, it should remove its approval via GitLab API, if it approved the MR before.

This should be triggered from both sides (I think?), GitLab pipelines as well as SonarQube project status changes, from red to green and vice versa within SonarQube.

However, for us, this exact workflow would be the most important:

1. GitLab pipeline is run
2. SonarScanner does its thing
3. SonarQube reports FAIL
4. Issues are fixed on the SonarQube side (“wontfix” for example)
5. SonarQube triggers GitLab to run the pipeline again
6. SonarScanner does its thing again
7. SonarQube reports PASS this time and approves the merge request
8. Code is changed
9. GitLab pipeline is triggered via push
10. SonarScanner does its thing again
11. SonarQube reports FAIL and removes its merge request approval
12. … the cycle continues …

SonarQube server details:

• SonarQube 10.6 (build 92116)
• Self-managed, deployed using Docker

GitLab server details:

• GitLab 17.1.6
• Self-managed

Best regards,
Timo Reichl

[Colin]

Hey Timo!

Personally, I agree we could go further with our Gitlab integration. I just want to check if this post is reallya different topic from what you’re asking about in your other thread, and if so how?

Adjust GitLab merge request decoration depending on SonarQube project status

Hello, we are facing a problem described as part of this issue: GitLab integration as external status check instead of failing the ci pipeline - SonarQube / Product Manager for a Day - Sonar Community (sonarsource.com). Quote 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 g…

If not, I’d just as rather keep the conversation to one thread.

[treichl (Timo Reichl)]

Hey Colin,

thanks for your answer! These two issues are similar, but different in say “goals”. Making API calls from SonarQube to GitLab and triggering Pipelines and such underlies both issues. But this issue aims more at adding/removing approvals, whereas the other issue aims more at merge request decorations themselves. It would be nice to have both, though.

Since both issues should be treated separately, I will edit my original post and remove the MR decoration part for more clarity.

Edit: Edited original post accordingly.

[Colin]

Ah, okay! I see the distinction between these two posts.

• Updating the summary comment when there’s a change that affects the Quality Gate SonarQube-side (marking an issue as false-positive). That’s the issue you mention here: Adjust GitLab merge request decoration depending on SonarQube project status
• Using the GitLab Merge Request Approvals API to handle the QG as a “check”/'status" rather than just a comment

@Farah, I think was responding to your second point when she responded here. She and I had a little behind the scenes chat about it (this approvals API has been on my radar for a while).

I will come back to your other post.

[treichl (Timo Reichl)]

Yeah, these points sum it up pretty much.

Just to reiterate: This specific issue (second point) is about the “Approve” button of a GitLab merge request:

The SonarQube QG = PASS event (no matter what triggers it) should “click” that button via API, so to speak. And the SonarQube QG = FAILED event should click the “Revoke approval” button via API.