Scanner command used when applicable: SonarCloudAnalyze task with msbuild configuration
Languages of the repository: C#
Only if the SonarCloud project is public, the URL: Project is private
Error observed: PR decoration is happening even when SonarCloudPublish task is not run
Steps to reproduce: Ran pipeline with parameter to run the publish set to ‘false’, and verified the task was not run in the resulting pipeline run.
Potential workaround: None
Additional info:
I had SonarCloudPublish enabled with a valid PAT token set up in SonarCloud previously. Tried disabling through project settings messing with the PAT for the relevant project, and got nowhere. Tried changing value of sonar.pullrequest.vsts.token.secured to garbage, run pipeline, SonarCloudAnalyze failed. Tried clicking reset button for the value, tried run, still failed, same error that the PAT is invalid. Then, I tried disabling the SonarCloudPublish task per the suggestion that the functionality is enabled by running it, from Configure page of the project under the .NET Azure Pipeline tutorial step 3 “Publish Quality Gate Result” section:
This task is not mandatory but will allow you to decorate your Pull Request.
If you plan not to use such a feature, you can omit it. Be aware that this task may increase your build time.
But somehow, comments are still being posted in my pull request, which I created after disabling the task.
Is it not possible to decouple organization-level PAT from the project PATs? I still want to be able to import projects into SonarCloud and run scans, but do not want pull request comments in Azure DevOps.
The SonarCloudPublish task kind of decorates your Pull Request, by leaving a Quality Gate in the build result. It is not actually responsible for commenting on your pull request (this is handled by SonarCloud). Today, it’s not possible to disable Pull Request Decoration on PRs triggered by the SonarCloud tasks unless you manually run the SonarScaner (which won’t set all the details SonarCloud needs to know to do the decoration).
Can you help us understand a bit more about why you want to disable PR decoration, so we understand if the use-case is something we should consider?
The SonarCloudPublish task kind of decorates your Pull Request, by leaving a Quality Gate in the build result. It is not actually responsible for commenting on your pull request
Ahh this lines up with what I was experiencing, thanks for the explanation. So probably I do want to publish the quality gate result every time.
Today, it’s not possible to disable Pull Request Decoration on PRs triggered by the SonarCloud tasks unless you manually run the SonarScaner
I see. The only reason I want to disable the pull request decoration right now is that it is posting way too many comments, and I want to block PRs from being merged until all comments have been resolved. But specifically I only care about comments from devs being resolved and not from the pull request comment decoration from SonarCloud.
I had a thought earlier today that the reason for so many comments may be that the target branch has not been scanned yet, so it is saying that we are adding a bunch of bad practices / bugs / code smells? If this is correct then I think for the PR to merge our CI/CD pipeline can just be force completed with unresolved comments.
Hi Colin, would really appreciate if you confirm my hypothesis:
I had a thought earlier today that the reason for so many comments may be that the target branch has not been scanned yet, so it is saying that we are adding a bunch of bad practices / bugs / code smells? If this is correct then I think for the PR to merge our CI/CD pipeline can just be force completed with unresolved comments.
If it is incorrect, this will cause problems with our dev work flow because no one is allowed to override required pull request checks:
I want to block PRs from being merged until all comments have been resolved. But specifically I only care about comments from devs being resolved and not from the pull request comment decoration from SonarCloud.
If the target branch is not yet analyzed, you will receive more bugs/code smells/vulnerabilities than just those that were introduced by the pull request. Making sure the target branch is analyzed should resolve this.
Sorry I meant that I would feel confident overriding the policy to resolve comments just to get the CI/CD pipeline into the branch we typically target, once I had confirmation that this would cause further PRs to receive fewer comments (that is, only comments related to code introduced in the PR) I am the admin for our DevOps org so I have the power to override those policies to force a merge, but our devs do not, so I didn’t want it to become a headache for them to work through 50+ comments on every PR going forward.
