My organization only had Azure Devops PR comment decoration enabled per project.
However, after moving the SonarCloud organization to be bound to the Azure DevOps organization then all our project have started to receive PR comment decoration. This is even though the individual project has not set “sonar.pullrequest.vsts.token.secured”.
How can I disable PR comment per project and still have bound organization.
Short of providing a rubbish token under project-level Administration > Pull Requests, there’s no opt-out mechnaism.
Can you discuss a little why you only want this enabled on some projects?
The reason is that not everybody in the company is that fond of SonarCloud and the way it is implemented. Some like the additional validation in PR while others would like this feedback loop to be part of the coding phase and not review phase. But since SonarCloud has centralized setup, then we have to align both .editorconfig coding rules and SonarCloud rules manually for each project which is a cumbersome task. SonarLint is not a good solution either as it now requires that I am connected to the server and the execution time is abysmal. It feels like going from using Git and back to SVN or similar version control solutions.
The feature of binding our organization to our DevOps sound good on paper and has some benefit, but if it imposes a lot of side effects, that we can’t even opt out of, then we would rather not have it. But we are now unable to go from bound to un-bound project as we can’t delete the PAT token in the organization.
There is a feature to disable PR decoration for GitHub repositories. Why not make this feature a general thing for a project, regardless of the repo?
My current solution to stop pestering all other teams with PR comment decoration is to add a read-only token on the organization level. Then it is possible to add a PAT token to the project if each project that would like decoration.
Hi @TomMalow and thank you for sharing.
I hear and understand your frustration. To be honest this is something we already considered but never prioritized as we didn’t have enough feedback on it.
Your post will help move this thing up in the list of things to fix.
Have a great day,
Christophe - DevOps Platforms PM
My company also need this feature. We don’t want to spam our devs for every PR