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

Support multiple instances of ALMs for pull request decoration



    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:



      Currently, it is not possible to have a SonarQube server decorate Pull Requests for several single GitHub Enterprise server, Bitbucket Server instance or Azure Devops Server.

      We have multiple customers who have several ALMs instances, and thus needs to be able to configure their project to decorate the specific ALM that the project is targeting.


      Use cases

      We should support the following use cases :

      • Single ALM instance (most cases)
      • Several ALM instances of one vendor
      • Several ALM instances of several vendors (less cases)

      As a SQ instance administrator I want to :

      • Control the overall configuration of the different instances of the different ALMs
      • Configure the different instances

      For GitHub :

      One SonarQube GitHub app is installed per GH organization. One GH instance can have several organizations, and each organization can have several project. The GH app can be installed for all organizations, for each organization (most cases) or for each repositories (few cases).

      => We want to configure multiple GH App per GitHub instance


      • unique identifier
      • API URL: url of the GH instance
      • GH App : The GitHub app that is installed on a GH organization
        • App Id
        • App private Key
        • (note: the App name is not needed for PR decoration)

      For Bitbucket Server :

      => We want to support multiple token per instance

      Properties :

      • unique identifier
      • URL of the BBS instance
      • BBS personal access token used to decorate PR

      For Azure DEvops Server:

      => We want to support multiple token per instance

      • Personal access token used to decorate PR
      • A unique identifier that the project administrator will be able to select at project level


      • Script the configuration of SQ via Web API (and not via properties file)
      • Delete an instance at global level.
        • Before deleting, I want to know how many projects are using this instance 
        • When I delete an instance at global level, this will also delete the configuration of all projects that use this instance


      As an administrator of the project I want to / I have to :

      • Choose the ALM instance of which the repository refers to and set the properties for my project. 
        • Properties for GH : GH instance + repository identifier
        • Properties for BBS: BBS instance + BBS project key + BBS repo slug
        • Properties for Azure Devops Server : the unique identifier provided at global level 
      • If there are several instances configured at global level, no instance is configured by default and I have to choose one.
      • If there is only one instance configured at global level, the instance is selected by default, and I just have to enter the project properties (only for GH and BBS)
      • Be able to delete/reset the instance configuration if I don't want PR deco anymore



      • People were passing/overriding sonar.pullrequest.provider and sonar.pullrequest.github.repository properties at project level to launch analysis. This is something we don't want to support anymore, and we will depreciate it. Until the depreciation :
        • If properties are present at scanner level and there is only one global conf per ALM -> display a UI warning to inform to not use those properties
        • If properties are present at scanner level and if there is more than 2 confs per ALM -> The analysis is performed, the decoration does not perform, and display a UI warning
        • In any case, when the conf is not correct to decorate PR (independently from the analysis), the decoration does not perform, and display a UI warning
        • Exception for Azure Devops Server: as the Azure plugin sets this property, there is no way to know if the user has passed the properties in parameter, so in this case we do not display a warning,


      Considerations to take into account : 
      • As we will support multiple instance, the properties key for defining GH APP make no more sense but the previous versions can still use them. We should support the fact that previous versions use those properties.


      Design solution



      Questions :

      • Do we use the GH App name for PR decoration (and what for?)? If not, we should remove it. If yes, the global administrator will enter it manually.
      • If the global admin delete a global instance that affects some project, the next PR decoration analysis will finish with a warning -> We should check what will be the warning and if it will be enough understandable for users. Otherwise we should update it to make it understandable. 


      Out of scope of this MMF:

      • the possibility to configure in the properties file
      • Delegate the configuration of ALM properties (GH url + GH app, BBS url + token, token for ADO) at project level (ie. overriding properties at project level)

      How ?

      • Add a global settings page for ALMs
        • Instance Admin can add any number of bindings (see WHAT for fields of each ALM)
      • Add a field in project settings to enable the project admin to select one of the configured bindings.


          Issue Links



              aurelie.boiteux Aurélie Boiteux (Inactive)
              aurelie.boiteux Aurélie Boiteux (Inactive)
              3 Vote for this issue
              11 Start watching this issue