Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-2036

Support multi-project for a mono-repository





      Currently, during the onboarding process, we let users import their repositories into SonarCloud and we make sure that 1 repo maps only 1 project. This is ideal to have something simple to understand. The problem is that it does not play nice with mono-repositories because:

      • They can contain several different “projects” that users want to analyse separately so that they master their build processes in the best way possible (i.e. they don’t want to build everything when only one part of the repository is impacted by a couple of changes)
        • The solution currently described in MMF-2001 would force them to rebuild and re-analyze everything every time a commit is pushed
      • Those different projects might be managed by different teams/team members, and this is not possible to reflect this organization in a single project on SonarCloud

      For those cases, some users have currently created several SonarCloud projects fed by analyses from one mono-repository. The problem being:

      • For the end-users:
        • The PR decoration (status of the QG + comments) does not work because the last project being processed erases everything
        • To be noted that apart from this, everything else seems to be working fine.
      • For us: we don’t have the link “SonarCloud Project → Remote repository” because those projects were created “manually”. This has several impacts:
        • We miss visibility on our internal data about projects
        • This prevents us from implementing some nice features (like checking/enforcing project visibility, automating permission updates, ...)
        • => All in all, we want to make sure that we can find a solution which still makes it possible to have these “SonarCloud Project → Remote repository” links.


      Use case

      • As a developer, I have several build pipelines set up on my repository. Some of them only are triggered upon a change, depending on where that change was. Each projects that are analyzed from those build pipelines will be updated, and I expect that the status of the QG related is updated and reported everywhere it should be (including on the Pull Request that might target multiple changed projects).


      To support mono-repos, we need to:

      • Update the project setup screen to allow having multiple projects for only 1 repository
        • The UI should make it clear that this is an advanced setup
        • Chances are that this UI will be the same whatever the ALM, but we can activate it step by step on each ALM as we progress on the support for mono-repositories
      • Allow SonarCloud to decorate 1 PR from multiple different projects
        • This should be done differently depending on the ALM

      Milestones of this Epic:

      1. Support for Azure DevOps - MMF-2068 [MUST]
        • This is where we have the biggest expectations
        • UI is not needed yet since project onboarding does not exist for Azure DevOps
      2. Support for GitHub - MMF-2069 [MUST]
        • In this step, we'll add the UI for the "Analyze Projects" page so that users can bind several projects to one repo
      3. Support for BitBucket Cloud - MMF-2070 [NICE]
      4. Support for GitLab ) MMF-2071 [NICE]

      Note: given the feedback on Discuss, we shall start by supporting PR for Azure DevOps and GitHub, and then do the UI for the Project Setup.

      Implement a metric that will count the number of project bound to a repository (either at creation or update of a binding), to get the % of adoption and the number of users using it.

      How ?

      See the related SC ticket


          Issue Links



              fabrice.bellingard Fabrice Bellingard
              martin.bednorz Martin Bednorz
              1 Vote for this issue
              11 Start watching this issue