SonarCloud support for mono-repositories in Azure DevOps Services and GitHub was recently added. This feature was requested by some of our users on the Community forum. We want to give you a little tour and explain how you can take full advantage of this feature!
First, let’s define mono-repository. Traditionally, software projects have been organized so that each project is stored within a single, distinct repository of its own. As software projects have become more complex and interconnected, some organizations moved to having all their projects in a single large repository. This is called the mono-repository, or monorepo strategy.
In a typical monorepo, each project occupies its own directory within the repository and each is independently buildable and deployable, though the exact setup depends on how the procedures that build each project are defined. In general, there are many ways that multiple projects can be arranged within a single repository. Fortunately, SonarCloud's support for the monorepo strategy does not depend on the specifics of the monorepo setup. SonarCloud relies on the fact that each project's build procedure can be configured to perform analysis and send the result to the corresponding SonarCloud project.
In the past, SonarCloud considered the code hosted in a repository as a single project. So naturally, the configurations in SonarCloud were at the repository level. The same applies to the feedback sent by SonarCloud in your ALM; it was also at the repository level. This was certainly a limitation for our users with many projects hosted in a single mono-repository. Well, we are happy to say that we now have a solution for this use case!
So if you have a single (GitHub or Azure DevOps Services) repository with multiple projects inside, you will now be able to:
- Configure one Quality Gate per project: you can customize your Quality Gate with the details of your project, and we advise you to do so!
- Receive multiple Quality Gate results: you can now rapidly check from the pull request if all Quality Gates passed before you merge!
- Read project-labeled messages from SonarCloud: you understand which project is relevant to SonarCloud’s feedback in your ALM so you can act accordingly!
In order to make use of this new feature, each SonarCloud project must have a unique project key across SonarCloud. We recommend using a pattern that includes your organization name, the SonarCloud project name, and an internal reference to the project within the monorepo (for example, myorg_myproject_frontend).
Currently, monorepo support is available only for GitHub and Azure DevOps Services repositories.
Let’s have a closer look at how to configure your monorepo:
- Go to the + (plus) menu on the top right of the SonarCloud interface and select Analyze new project.
- This will take you to the Analyze projects page
- Now click Setup a monorepo (it is a small text link on the lower right of the page). You will now be on the Import monorepo page.
- Select the organization and then select the monorepo repository that you want to import.
- For each project contained in your monorepo, add a corresponding SonarCloud project by clicking "Add new project". You have to choose a unique project key for each SonarCloud project. As mentioned above, these are the keys that you will use when configuring your CI service (see below) to bind each monorepo project to its corresponding SonarCloud project.
You can convert a standard project to a monorepo by doing the following:
- On the Analyze projects page
- you can add one or more additional project keys to an existing standard project. This will convert that new set of projects to a monorepo configuration.
For more information on how to configure your mono-repository, please check the documentation here.
Whether you've been waiting for this, or you’re new to SonarCloud, you should now be able to take full advantage of this mono-repository feature! We hope that it will bring more accuracy to your Code Quality and Security strategy. Let us know how it goes!