Skip to main content
GSA Logo

Cloud Economics

About MCaaS

SonarQube

Sonarqube provides static code analysis to pipeline jobs. This can be useful for detecting vulnerabilities, bugs and code smells. MCaaS offers a JTE pipeline library to easily add this to jobs.

Installation

MCaaS manages Sonarqube deployment and integration with Jenkins. Both the Sonarqube Enterpise Edition and Community Edition are available, though the Enterprise Edition requires a license to use.

The Community Edition is free to use, and easy to integrate into new and existing MCaaS tenant Jenkins pipelines.

Enterprise Edition URL- https://sonarqube.prod.core.mcaas.fcs.gsa.gov/

Community Edition URL- https://sonarqube-ce.prod.core.mcaas.fcs.gsa.gov/

SonarQube Groups

MCaaS Sonarqube is integrated with Helix Github. Upon logging into Sonarqube through Github OAuth, Helix Github users will automatically be placed into any Github teams that have been synced into Sonarqube.

Adding a Github Team into Sonarqube

This step must be completed by MCaaS. Please create a ticket asking for a Helix Github team to be added as a group in Sonarqube. The required convention is <Github Org>/<Github team within org (all lowercase)>

Once a Github team has been added as a Sonarqube group, members of that team will be able to log into Sonarqube and assume permissions available to that group.

Adding/Modifying Sonarqube Group Permissions

Group permissions can only be modified by an MCaaS engineer. Please create a ticket with MCaaS if permissions need to be modified. A common occurance would be to add a new project to a group.

Add Sonarqube to your Jenkins config

pipeline_config.groovy changes

libraries{
  ... # other libraries

  sonarqube{
      installation_name = "sonarqube-ce"
      credential_id = "prod-sonarqube-ce"
      wait_for_quality_gate = false
      unstash = ["workspace"]

      # suggested setting to ensure a unique project name is created in Sonarqube, mapping to the repo url. Overrides `sonar.projectName` in sonar-project.properties file
      cli_parameters = [
          "-Dsonar.projectName=\"ogp: \$GIT_URL\""
      ]
  }
}
  • [Optional] Provide ability for a repo to opt-out of Sonarqube analysis by promotion level. This can facilitate Sonarqube adoption across repos as they become ready.
application_environments{
  development{
    ... # other config
    sonarqube{ 
      do_not_run_on_these_repos = [
        "<repo https git url to skip>",
        "<another repo https git url to skip>"
      ]
    }
  }
  test{
    ... # other config
    sonarqube{ 
      do_not_run_on_these_repos = [
        "<repo https git url to skip>",
        "<another repo https git url to skip>"
      ]
    }
  }
  staging{
    ... # other config
    sonarqube{ 
      do_not_run_on_these_repos = [
        "<repo https git url to skip>",
        "<another repo https git url to skip>"
      ]
    }
  }
  production{
    ... # other config
    sonarqube{ 
      do_not_run_on_these_repos = [
        "<repo https git url to skip>",
        "<another repo https git url to skip>"
      ]
    }
  }
}

Jenkinsfile changes

Your MCaaS Jenkins pipeline is flexible for when to run Sonarqube. Two general approachs are shown below:

Always Run Sonarqube

Your Jenkinsfile can be set to always run Sonarqube during all pipeline executions. This can be configured following this example:

 lines (42 sloc)  1.86 KB
   
on_pull_request from: feature, to: develop, {
        static_code_analysis()
        mcaas_build_and_push()
}

on_merge from: feature, to: develop, {
        static_code_analysis()
        mcaas_build_and_push()
        mcaas_retag(env.GIT_SHA, "dev-"+ env.GIT_SHA)    
}

# add static_code_analysis() to the rest of the defined build triggers for other promotion levels

Conditionally Run Sonarqube

Another option is to only run Sonarqube for specific repos, git events, or promotion levels. This can be done by the following conditional, when implemented in conjunction with the Application Environment changes shown as an optional step above:

on_pull_request from: feature, to: develop, {
        mcaas_build_and_push()   
}

on_merge from: feature, to: develop, {
        if(!(development.sonarqube?.do_not_run_on_these_repos?.contains(GIT_URL))) static_code_analysis()
        mcaas_build_and_push()
        mcaas_retag(env.GIT_SHA, "dev-"+ env.GIT_SHA)    
}

In the above snippet, Sonarqube will only run on merge from a feature branch to development (not on pull request), and will only run if the build job's GIT_URL is not included in the repos to skip list defined in the development application environment.

Add Sonarqube Properties to a Repo

sonar-project.properties must be present in a repo that Sonarqube will scan. This properties file tells Sonarqube which directories to scan and to skip, among other analysis-parameters.

The following example is the configuration for a very simple MCaaS demo app.

sonar.projectKey=demo
sonar.projectName=demo # optional, overridden by cli_parameters -Dsonar.projectName in library config snippet above
sonar.projectVersion=1.0
sonar.sourceEncoding=UTF-8
sonar.sources=app.py
sonar.exclusions=**/node_modules/**,**/*.spec.ts

Refer to the Sonarqube documentation for more information about avaialble analysis-parameters. This repo of example Sonarqube configs may also be helpful.

Permission to Access Sonarqube UI for a Project

Initial tenant onboarding to Sonarqube requires MCaaS to create a Sonarqube group corresponding to a Github team. When requesting that MCaaS onboard you to Sonarqube, please specify with Github team within your Helix Github Organization you want mapped to Sonarqube. For more detail on Sonarqube group delegation, see Sonarqube Groups above.

MCaaS may need to add your Github team to newly created Sonarqube projects for you to be able to access them. If you add a project, and you cannot access it in the Sonarqube UI, create a Standard FCS Support Request asking MCaaS to add your team to the project.

    On this page:
test