Currently, during the onboarding process, we let users import their repositories into SonarQube and we make sure that one repo maps only one project. This is ideal to have something simple to understand. The problem is that it does not play nice with mono-repositories and a lot of users struggle with those setups. The main problem is : when a PR is opened, when a change occurs in the repo, every project linked to this monorepo will push the result of its own analysis, thus overwrite the QG status and the PR comments.
For those cases, some users have currently created several SonarQube 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.
Also, the onboarding doesn't work well, as you cannot import a project from a repo you already imported in SQ.
Use case 1
- As a user, I have several build pipelines set up on my mono-repository. Each build pipeline correspond to a different project inside my mono-repo. Each build pipeline is configured to run a different SQ project. When I update one of my repo project, the corresponding build pipeline is triggered.
Use case 2
- As a user, I have one build pipeline set on my mono-repo. This build pipeline is triggered upon any change on any of the project contained in my repo. In this build pipeline, I configured one SQ analysis per repo project. When I update one of the project, the build pipeline is triggered and analysis are triggered for every SQ project related.
For both uses cases,
- I expect that the status of the QG related to this build pipeline is reported in my ALM if any PR is already opened, as well as comments. This should not overwrite QG+comments related to another SQ project relating to this repo.
- I expect to be able to clearly understand to which project my QG+comments apply to.
- I expect to have clear indication that monorepo is supported at some point for EE+ only.
In any case, if I migrate from a previous version of SQ, I should be able to link my existing SQ project to a mono-repo.
Ideally, we want to address all ALMs, starting with Azure DevOps, Bitbucket and Github.
- The onboarding experience will be treated in a different MMF. This only concerns the technical ability to decorate PRs on mono-repos.
ALMs are listed by order of priority:
- Azure DevOps Server
- Bitbucket Server
They should be treated as milestones, and potentially "cuttable" branches.
With this new milestone, we expect to bring the support for BitBucket Server, GitHub and GitLab.
- Make Quality Gate Report SonarQube Project specific (
- Make GitHub Checks SonarQube Project specific (
- Add the SonarQube Project name to the summary comment (
- Delete only the MR comments related to a given SonarQube Project (
- Add the SonarQube Project name to the MR comment (
As a Baby Step, we do not store any state in order to know if a PR was migrated to the new mono-repo format or not. Instead, we make an initial pass using the "old" method (same as in DE), removing any existing comments, checks, reports, etc. Then, in a second pass, we use the "new" method (project-specific decoration) to:
- Remove any existing project-specific decoration, when it needs removing
- Post new project-specific decoration
- Update existing project-specific decoration, where applicable
This implies we make extra API calls for each PR/MR decoration, regardless of the fact if the SonarQube Project is part of a mono-repo or not. We accept this slight overhead, as it allows to keep the code simpler. As mono-repos are a EE+ only feature, this does not apply to DE, which will continue to work as before.
- On each PR decoration, use the "old" report key to delete any existing reports
On each PR decoration, use the "old" identifiers to:
- delete any existing comments
- delete any existing checks
- On each MR decoration, use the "old" identifiers to delete any existing notes
- Add mention of mono-repo support in ALM integration pages