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

Administrators create SQ projects from GitLab repositories and have the PR decorated



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


      Why ?

      To provide tight integration between SQ and GitLab and in the scope of providing minimal steps to have first branch and PR analysis, project administrators should be able to create SQ project from GL repositories when they integrating quality in their development pipeline, and have everything configured on SQ side to decorate the project's PR.

      SQ developers should be able to access them as soon as the projects are created.

      What ?

      Success criteria

      Trend of the number of newly created bound projects vs the number of not bound projects 

      Use cases

      1. Main use case (must have) : Small company, small team with 1 GL instance

      • As project administrator, when I want to create a project to analyse one of my GL repositories, I want to be guided to set up my project and analyse my project. 
      • Once I have created several projects from the UI, I know how to configure project and, if I want to go faster, I will have the possibility to automatize the creation and configuration of projects on which I can launch PR analysis

      In EE, if my instance administrator configured several GL instances, I see that the onboarding on several GL instances is not supported and I cannot create projects from GL using the onboarding process.

      When I add a repository on GL side, I want to see this repository on SQ side, and be able to create a SQ project from it.


      2. Multiple repositories import

      Large companies should be able to automate the import of several repositories.

      Must have: via web API



      We assume that GitLab connection is already configured at global level.
      As a user, I will be offered to import a GitLab repository only when my GitLab connection is configured.

      As a user who has the permission to create a project in SQ, when I want to integrate quality in the dev pipeline and I want to decorate PR, I need to create a project in SQ, and I need to :

      • Generate a Personal Access Token to get the list of the repos for which I have read permissions on GitLab.
        • I should understand why I need to provide a PAT: I need to authenticate myself to get the list of the repos I have read permission
        • I will follow a link that will get me to the correct place to generate the PAT in GitLab
        • I will copy this PAT and paste it in SQ
        • I will see the list of my projects
      • See the list of GitLab repositories for which I have read permission
        • I cannot import a repository that is already imported (meaning already bound to GitLab repository).
          (Nice to have) It includes manually created projects with Merge Request configured.
        • the Project Id in the MR decoration config becomes mandatory (in the settings page only). The MR decoration keeps working, we display a warning to advise users to complete the configuration (offer a migration path).
      • Select the repository for which I want to set up quality analysis for, and be able to follow the tutorial to set up my analysis.
        • I want to follow the tutorial just after 
        • (Nice to have) See my project created with a link to the GitLab repository and GitLab project
      • Once my project will be created, it should be clear for me that I don't need to do any extra configuration in SonarQube to decorate MRs. Documentation should be clear about this.
        With the next MMF, once my project will be created and configured to be analyzed, I will know that the whole configuration is done.



      For GitLab API authentication, we will rely on the GitLab personal access token mechanism. Once a token acquired, we will be able to fetch projects from the GitLab endpoint `GET /projects` documented here: https://docs.gitlab.com/ee/api/projects.html#list-all-projects


      Backend API impact:

      • PAT handling: we want to reuse SQ endpoint that we created for BBS, and adapt it to be used for GitLab as well:
        • "POST api/alm_integrations/set_pat" No signature change, only the behavior will change to accept Gitlab input
        • "GET api/alm_integrations/check_pat" No signature change, should now accept GitLab almSetting key as input
      • Create a new endpoint "GET api/alm_integrations/search_gitlab_repos". Requires the 'Create Projects' permission.
        • Input parameters :
          • "almSetting", required, ALM setting key, max length 200
          • "projectName", optional, Project name filter, max length 200
          • "p", optional, page index
          • "ps", optional, page size
        • Pagination: page parameters are optional, paging result is always returned in the result
        • returned payload:
        • {
             "repositories": [
                   "name":"My imported repo!", // gitlab "name" field
                   "slug":"my-imported-repo", // gitlab "path" field
                   "namePath":"Top Group yyy / Sub Group XXX", gitlab "name_with_namespace" field, without the name
                   "slugPath":"topgroup-yyy/subgroup-xxx", gitlab "path_with_namespace" field, without the path (slug)
                   "url":"http://gitlab.com/group-xxx/my-imported-repo", // gitlab "web_url" field
                   "sqProjectKey":"topgroup-yyy_subgroup-xxx_my-imported-repo_ e09d45ec" // populated only if the GL project is already binded, null otherwise
                   "name":"My repo!",
                   "namePath":"Group YyY / Sub Group zzZ", gitlab "name_with_namespace" field, without the name
                   "slugPath":"group-yyy/subgroup-zzz", gitlab "path_with_namespace" field, without the path (slug)
                   "url":"http://gitlab.com/group-yyy/another-project", // gitlab "web_url" field
      • Create a new endpoint "POST api/alm_integrations/import_gitlab_project", Requires the 'Create Projects' permission
        • input parameters:
          • "almSetting", required, ALM setting key, max length 200
          • "gitlabProjectId", required, GitLab project id, max length 200
      • GitLab MR setting page: Project Id becomes mandatory
        • Analysis impact: we should display a warning during the analysis to raise awareness about the fact that this id is now mandatory
        • Api impact :
          • POST api/alm_settings/set_gitlab_binding, parameter "repository" is now mandatory
      • GitLab API usage

      We will use the "GET api/projects" endpoint, we should use the following parameters: simple=true&membership=true&order_by=name&sort=asc


      repo mapping:
      As we can have several GitLab projects, the GitLab repository name is not unique. We need to generate a key to duplicate them. The mapping will be done with:

      SQ project key = max250characters(replaceSlashWithUnderscore(path_with_namespace + "_" + a generated uuid))
      if the path_with_namespace is longer than 250 characters, we keep the 250 last character. That would keep the most important part of the slug.


        1. pat2.png
          117 kB
        2. repo-selection.png
          101 kB
        3. repo-selection-inline.png
          113 kB
        4. repo-selection-radios.png
          118 kB

          Issue Links



              christophe.havard Christophe Havard
              christophe.levis Christophe Levis
              0 Vote for this issue
              1 Start watching this issue