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

Support branch and merge request analysis in GitLab CI





      In order to integrate at best with GitLab, we want to allow GitLab users to trigger analysis of their projects from GitLab CI.


      Use Cases

      As a developer, I want to configure GitLab CI to analyze my repository. I expect to follow a documentation (potentially with sample projects) to guide on what to do:

      1. I generate a user token which will be used to trigger the scan
      2. I make this token available as a SONAR_TOKEN env variable available for my pipeline
      3. Depending on which build technology I use, I copy-paste a command (available from the doc) into my GitLab CI file
        • For Maven, it should be as simple as mvn clean verify sonar:sonar
        • For Gradle: ./gradlew.sh sonarqube
        • For other type of projects: sonar-scanner
          • I expect the doc to tell me that I need to also push a sonar-project.properties file in this case
      4. Once I push this change, I expect a first analysis to be triggered and soon after to have the first results visible in SonarQube
      5. Whenever I create a new branch which contains this updated GitLab CI file, I expect the branch to be automatically analyzed and to appear in SonarQube
        • If it's the first analysis, the analysis should not fail, the project should be provisioned (see SONAR-11155)
        • Analysis will not fail when Quality Gate is red, this will come in next iteration
      6. Whenever I create a Merge Request (MR for later use) on a given branch, I expect this MR to appear in SonarQube once analysis is done
        • Note 1: I expect to see "Merge Request" in the SonarQube UI instead of "Pull Request"
        • Note 2: in this MMF, we won't go to the "decoration" stage of PR/MR. I.e. users won't see anything in GitLab UI in this iteration. 


      • To make the GitLab CI configuration as simple as possible:
        • SonarQube should automatically detect configuration from the GitLab environment variables so that the user doesn't have to configure manually the analysis with the branch name, PR parameters.
        • We should find a way to set "globally" the URL of the SonarQube instance, a bit like what is done for the token
          • E.g. make a SONAR_URL variable known to the scanner engine
          • Or ask the dev/admin to configure the SONARQUBE_SCANNER_PARAMS globally to specify the "sonar.host.url" property
      • For maven and Gradle projects, SonarQube analysis can rely on the corresponding analyzers.
      • For non-Maven/Gradle projects, SonarQube could rely on a Docker image to provide the Scanner CLI
      • What happens when SQ is in CE?
        • We document the fact that only the main master should be analyzed


      To detect that the build is taking place into a GitLab environment, search for the variable $GITLAB_CI

      Detect that the build is for a branch :


      Detect that the build is for a merge request : $CI_MERGE_REQUEST_ID




          Issue Links



              christophe.levis Christophe Levis
              christophe.levis Christophe Levis
              4 Vote for this issue
              9 Start watching this issue