Pull Request integration with mutliple Build Pipelines results in incorrectly deleted comments

Get help SonarCloud
#1
  • ALM used: Azure DevOps
  • CI system used: Azure DevOps
  • Scanner command used when applicable (private details masked)
  • Languages of the repository: C#

In our environment we have several Visual Studio solutions in a single Azure DevOps Git Repo. (This was done for management purposes.) Each build represents a Visual Studio solution within the repo. Each build is associated to a SonarCloud project.

When a Pull Request is created, Azure DevOps (through the branch policies) is able to kick off multiple builds; which results in multiple SonarCloud analysis runs.

When the first build is analyzed, the PR receives the comments from SonarCloud. When the second (or any later) build is analyzed, the previous analysis comments from SonarCloud on the PR are deleted. This makes it hard to track the comments from multiple builds.

Instead of deleting the PR comments, could there be an option to leave the comments available and mark them “Closed” or “Resolved”?

I understand the best approach would be to refactor our code base so that each Visual Studio solution is in it’s own Git repo, but the team has pushed back on this for various reasons.

#2

Hi @W0GER and welcome to the community.

Thank you for your feedback.

So, to sum up, you have currently

  • Project1 (P1)
  • Project 2 (P2)

When you create a PR targeting the Project1, it triggers a build for P2 as well, and you are saying that the P2 PR delete and overwrites comments in P1 PR ?

Thank you.

#3

Yes that is correct.

#4

Have you set correctly the SonarCloud project keys in the Prepare Analysis Configuration according to your configuration ?

#5

Yes, each build (P1 and P2 in your example) has the Project Key correctly set in the Prepare Analysis Configuration task. We use the $(Build.DefinitionName) variable to drive the project key field. The projects are correctly setup with that key in SonarCloud.

#6

P1 and P2 have different Build definitions

#7

OK so i think i got it

The current behavior of SonarCloud is to wipe out every comment once a PR build is triggered, in order to display fresh new comments if needed (limited to 20 by design).

A part from adding a intelligence to not build or at least not trigger an analysis if the build is not intended to be triggered, i don’t see any workaround for this.

#8

When the SonarCloud comments are created, if it could add some additional meta-data indicating which project the comment is associated with; then the removal code could just remove those comments where the meta-data matches the current project.

#9

That explains the disappearing comments. With respect, that’s a terrible design choice. The comments should never be removed because it allows minor issues to slip through without an assessment by the reviewer. For example, if there are code smells that are introduced in a pull request, those likely won’t fail the quality gate (certainly the default quality gates). In Azure DevOps / VSTS (for example) there is a standard rule that all comments have to be resolved before proceeding. By deleting the comments (and leaving orphan replies) there’s no reasonable way to enforce this requirement.

#10

They should “re-appear” if they are marked as “not resolved” on SonarCloud anyway.

#11

But they don’t always, which might be because you’re limiting the number of comments per analysis to 20 (if I read that correctly)

#12

We faced with the same issue in Azure DevOps. We have two SonarCloud projects, one for .net backend and second for typescript frontend part. Both of them are analyzed in single PR using two separated “analyze” tasks in pipeline. As the result we have the comments in PR only from the second “analyze” task. The comments produced by the first “analyze” task are deleted. Does anybody have any recommendations how to solve it?

#13

Hello there,

We are very happy to announce that we added support for mono repositories on Azure DevOps.

From now on you will be able to:

  • Have a Quality Gate per project on your Pull-Request statuses
  • Up-to-date comments on your PR from each project that were analyzed

Please take a look at the guide on our documentation for more details on how to set it up.

2 Likes
#14

@mickaelcaro,

Thanks for the update on this, but I’m a bit confused. The documentation states:

Convert a standard project to a monorepo

On the analyze projects page you can also add one or more additional project keys to an existing standard project. This will convert that new set of projects to a monorepo configuration.

We current having a repo, Microservices, that has several Visual Studio Solutions. Each Visual Studio Solution has it’s own Azure DevOps build, each build has it’s own SonarCloud project. Therefore there is a 1:1 relationship of Visual Studio solution to SonarCloud project. This was setup before SonarCloud implemented monorepo.

Sometimes due to the way the teams work, a PR may contain changes for more than one Visual Studio Solution, so a PR could have multiple builds that would update multiple SonarCloud projects.

With our current setup, do we need to change anything to take advantage of the monorepo feature?

#15

Hi @W0GER,
What you have to do is activate the " Enable support for monorepo" setting in your project’s settings (under the Administration -> General Settings menu, then General).

What will be done with that ? Each new Quality Gate status posted for a PR will contain a unique identifier for your project, allowing the PR to receive multiple ones. Also, for each comment posted if there’s a codesmell/bug, this one will contain the name of the project so that you can quickly identify to which it belongs.

HTH,
Mickaël