We are using SonarCloud to decorate pull requests in Azure DevOps. This works fine if there are only a small amount, say about 20-25, issues found for a scanned project. Then all these 20-25 comments are placed in the pull request. No problem. But when more issues, say 100, are found in a pull requests it doesn’t decorate them all but seems to split them up. It looks like it limits the pull request decoration to about 20-25 comments. When we fix the code issues found and a new scan is done, it finds the next 20-25 issues and decorates the pull request with those issues found. In say 100 issues are found, we would expect all those 100 issues to be decorated in the pull request immediately. If we look at our pull request branch in SonarCloud itself all issues are immediately reported. It looks like the pull request decoration in Azure DevOps is then broken up into smaller steps.
I can see in the code that we decorate max 20 issues on Azure DevOps. I don’t know why we have this limit, I suspect API limits or fear of noise may be important factors. I’ll ask my colleagues and keep you posted.
What if there are 1000+ issues? Would you want all issues to be decorated, without a limit?
Good to read that there is indeed a hard coded limit which explains our observation. I discussed this with a colleague of mine and would it be an idea to at least show a comment/decoration in the pull request when more than 20 issues are found? Where the comment says something like “The maximum amount of decorations (20) has been reached, please see SonarCloud for the full report.”?
Or would it be an idea if the amount of decorations can be made configurable, so that we can decide how many decorations there should be made (via a properties configuration in an Azure DevOps pipeline task)?
Regarding your question about when 1000+ issues are found, I think that is indeed an extreme situation which you do not want. But the limit of 20 is relatively low I think.