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

Support branch and merge request analysis in GitLab CI

    XMLWordPrintable

    Details

      Description

      Why

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

      What

      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. 

      Solution

      • 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

      How

      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 :

      sonar.branch.name=$CI_COMMIT_REF_NAME 
      

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

      sonar.pullrequest.key=$CI_MERGE_REQUEST_ID
      sonar.pullrequest.branch=$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
      sonar.pullrequest.base=$CI_MERGE_REQUEST_TARGET_BRANCH_NAME
      

       

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              christophe.levis Christophe Levis
              Reporter:
              christophe.levis Christophe Levis
              Votes:
              4 Vote for this issue
              Watchers:
              9 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: