Monorepo coverage report not reliable for monorepositories

Get help SonarCloud
, , ,
#1

Template for a good new topic, formatted with Markdown:

  • ALM used: Bitbucket Cloud
  • CI system used: Bitbucket Cloud

We are using a monorepo with several modules/microservices. As such, only one or few of them are changed in every PR and merge into master. Our CI pipeline only runs for the modules that have been changed. As a result of this configuration, coverage reports are generated only for the modified modules, which leads SonarCloud to think that the whole project coverage is much lower than it actually is.

I turned on the monorepo configuration but it doesn’t seem to help. Does anyone have a solution to show a reliable coverage report in the master branch?

Thank you.

#2

Hi @Miguel_Molina

So you mean that your monorepo targets only one single project on SonarCloud ?

I’m afraid that this is not fully supported yet. What i can propose to you is to have 1 SC project per module/microservice, so then each of them will have its own computation of QG, coverage, …

Does that make sense for you ?
HTH,
Mickaël

#3

Hi Mickaël,

Thank you for your answer. That is an alternative that would cost us a significant amount of CI time. We are using bitbucket pipelines with your integration pipes. It seems that the cache doesn’t store the pipes so they have to be downloaded every time. If I multiply that by the number of modules in our repo it will take much longer and be more expensive. That’s the reason of using only one SC project, also what is the benefit of activating the monorepo option in the project configuration?

Alternatively, I was thinking of storing the coverage reports of each module/microservice in a private cache within the pipeline and updating only the coverage files after a source or test modification. Do you think SC will be able to find the coverage files in file different from the projectBaseDir? Would this work?

Thank you,
Miguel

#4

Python coverage reportPaths property supports comma-delimited values, so as long as the file paths (inside the coverage files) matches the files you just analyzed, it should be ok.

#5

Hi Mickaël,

I tried caching the coverage.xml files but for a reason I don’t understand Bitbucket doesn’t update the cache with the new files.

I also tried your proposal and I included the pipes in the test step of each microservice and created a sonar-project.properties under the base dir of each of them. The pipelines run smootly but I don’t get any update in SonarCloud. Shall I add each project manually? May it be that they do not show up until I merge into master?

#6

Hi Miguel,

If you are not analyzing the default branch of the repo, there will be no ‘auto-provisionning’ of the project on SonarCloud (if it has not been created yet). Most generally, this feature will be removed soon on our side, so we suggest to create by hand your project at first, then analyze the default branch, before doing anything else.

Mickaël

#7

Hi Mickaël,

I see two problems with splinting the analysis in separate projects:
1.- We will be loosing the integration with the widget showing in Bitbucket the quality metrics in the repository.
2.- Will pull request be decorated?

Thanks again,
Miguel

#8

So yes this is the drawback, monorepo is not yet supporter for BitBucket on SonarCloud, PR and widget will be overriden each time a new analysis will come for a given commit.

#9

Thank you for the confirmation.

I have another question. When I run the the pipes for each module independently, the quality gates fail the build if they are not met. But this is not the behavior when using sonar.modules at the repo level. Is this the expected result or am I misconfiguring it?

Would it be possible to open a ticket to include monorepo support for Bitbucket?

#10

sonar.modules has been deprecated since a long time, and should not be used anymore. Are you still using it on your side ?

You can upvote this MMF : https://jira.sonarsource.com/browse/MMF-2070

#11

Yes. We’ve just got our SonarCloud account in a paid plan for our organization and integrated our repository. This is taking more effort than I expected. Would it be possible to have a meeting with you to explain our case and solve the current issues.

#12

I’m sorry this is the only place here where we can provide support for SonarCloud.

I understood you case and unfortunately, given the things that we currently support, will not be easy out-of-the box, if not impossible, and i’m afraid of that.

In all cases, about your coverage, we don’t have any algorithm that detect and calculate the coverage on master for a subset of modules, it will always be on the full project.

#13

Thanks Mickaël. What alternative you offer to sonnar.modules? The quite handy and work smoothly.

#17

Hi @Miguel_Molina

The only alternative is to scan the entire project, and not use sonar.modules anymore, but as i said, we don’t support partial analyses currently on SonarCloud.

Mickaël