This comment suggests that the only resolution is to remove the GitLab integration from the project settings.
I don’t see any integration settings at the project level. At the organization level, I can add an access token, but can’t remove it. What is the procedure to remove the GitLab integration?
I attempted to work around this by removing the GitLab bot user, but that unsurprisingly causes other problems. In particular, scanning on GitLab CI failed with GET 401 https://sonarcloud.io/api/alm_integration/show_pullrequest?project=XXX&pullrequestKey=YY. This suggests to me that disabling GitLab integration will result in the loss of other useful features. Is this the case?
Consider this a vote for improved GitLab support. The comments (or ideally, some deeper integration) are useful, but at the current volume — a new comment for every subproject for every build — they simply overwhelm the thread.
we got rid of the spam comments by removing the GitLab integration at project level.
You can find it at “Project Settings → General Settings → DevOps Platform Integration”.
There should be no configuration name selected to disable the integration.
I agree that this is just a workaround and the Gitlab integration should be improved.
Thanks for the reply Carsten_HB. Unfortunately, on SonarCloud, I can’t find a Project Settings item. At the project level, there’s Administration → General Settings, but no DevOps Platform Integration setting. Searching the settings for devops only surfaces the Azure-specific monorepo setting. From my Googling it looks like DevOps Platform Integration may be a SonarQube setting instead.
Indeed it is not possible to turn off comments on SonarCloud in GitLab.
I understand multiple comments could bring too much noise. Could you elaborate on how comments would help you at best?
The two main issues from my perspective are the number of comments and the number of notifications. I have 14 subprojects in the monorepo, which means that every push to a merge request triggers 14 notifications and adds 14 comments to the MR. (Even though the old comments get deleted, 14 comments alone are noisy, and something developers are likely to skip over rather than read through.)
I think what would work better for a monorepo setup would be a single comment rather than one for each component, ideally edited on update rather than replaced to eliminate subsequent notifications. The fact that we can fail the pipeline with the quality gate setting means that the comment only needs to provide a quick summary and quick access to the details of the failure. Ideally there would be a deeper integration that didn’t rely on comments at all, but I appreciate that that’s a bigger ask.
I think for our purposes right now I will try a single project setup and/or recreate the projects as unbound.
Thanks for the clarification.
I understand for a monorepo with multiple sub-projects, it is not very convenient.
This is not something planned in the short term roadmap. We will keep track of your request and monitor if we have others in the future.
I’d like to add that we find the lack of ability to disable GitLab notifications on merge requests extremely inconvenient and frustrating at our organization as well.
