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

Support for PR decoration for mono-repositories in AzureDevOps Server

    Details

    • Type: MMF
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Fix Version/s: None
    • Labels:

      Description

      WHY:

      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.

      WHAT:

      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.

      Out of scope

      • 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:

      1. Azure DevOps Server
      2. Bitbucket Server
      3. GitHub
      4. GitLab

      They should be treated as milestones, and potentially "cuttable" branches.
      With this milestone, we want to bring the support for Azure DevOps Server.

      HOW:

      1 - Support PR/MR decoration for mono-repos

      1. Make Quality Gate Status SonarQube Project specific (SONAR-14272)
      2. Make PR comments on Azure DevOps Server SonarQube Project specific (SONAR-14286)
      3. Delete only the PR comments related to a given SonarQube Project (SONAR-14273)
      4. Display mono repository information in Pull Request Decoration project settings (SONAR-14334)
      5. Nice to have: Display list of linked projects (SONAR-14336)

      2 - "Migrate" existing PR/MR decorations

      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.

      (SONAR-14281)
      On each PR decoration, use the "old" context to:

      1. delete any existing comments
      2. delete any existing quality gate statuses

      3 - Documentation

        Attachments

        1. azure_status_comments.png
          azure_status_comments.png
          304 kB
        2. bb_report.png
          bb_report.png
          456 kB
        3. gh_check_name.png
          gh_check_name.png
          148 kB
        4. gh_comment.png
          gh_comment.png
          69 kB
        5. gl_comment.png
          gl_comment.png
          201 kB
        6. Screenshot 2020-12-10 at 14.19.38.png
          Screenshot 2020-12-10 at 14.19.38.png
          108 kB
        7. Screenshot 2020-12-10 at 15.37.02.png
          Screenshot 2020-12-10 at 15.37.02.png
          72 kB

          Issue Links

            Activity

              People

              • Assignee:
                christophe.levis Christophe Levis
                Reporter:
                christophe.levis Christophe Levis
              • Votes:
                3 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: