How do you prefer to set configurations?

Clean Code Discussions
1

Some analysis properties, such as sonar.projectVersion have to be set in a properties file (sonar-project.properties) or on the command line. Some, such as exclusions, can be set in the UI. And some, think Quality Profiles & Quality Gate, have to be set in the UI.

Where you have a choice, what do you choose, and why?

What’s your ideal state for setting analysis-level (project-level… global) properties?

1 Like
5

We have several repositories using Sonar. We prefer to use the UI for configuration the least possible and prefer Configuration as Code as much as possible. Things like Quality Gates and other Org level settings, we do configure from the UI, but for project specific stuff we absolutely avoid the UI.

Most of our repos will have a standard sonar-project.properties file on the command line and that property file has some values that can come from environment variables.

For example:

sonar.projectKey = ${env.SONAR_PROJECT_KEY}
sonar.organization = ${env.SONAR_ORGANIZATION}

sonar.projectVersion = ${env.PROJECT_VERSION}
sonar.projectBaseDir = ${env.WORKSPACE}
sonar.sources = ${env.WORKSPACE}
sonar.tests = ${env.WORKSPACE}
sonar.sourceEncoding =  UTF-8

sonar.exclusions = \
  ${env.SONAR_ADDITIONAL_EXCLUSIONS},\
  build/**,\
  **/vendor/**

sonar.coverage.exclusions = \
  ${env.SONAR_ADDITIONAL_COVERAGE_EXCLUSIONS},\
  test/**,\
  **/test/test_*.py

The script that calls sonar runner can then set these environment variables as needed per project and some of the values can be set automatically such as the project base on the current git information for example.

This is better than ending up with an extremely long list of command line options.

The shell script will typically be (assumes running from Jenkins):

#!/bin/bash

export TEST_REPORTS_DIR=build/test_reports
if [[ $CHANGE_ID ]]; then
    # For PRs the head of the branch before the local merge is what we are looking for.
    git log HEAD@{1} -1 -q | head -1 | cut -f 2 -d' '
    sonar_args=(
        "-Dsonar.pullrequest.key=$CHANGE_ID"
        "-Dsonar.pullrequest.base=$CHANGE_TARGET"
        "-Dsonar.pullrequest.branch=$CHANGE_BRANCH"
        "-Dsonar.scm.revision=$(git log HEAD@{1} -1 -q | head -1 | cut -f 2 -d' ')"
    )
else
    branch="$(echo $GIT_BRANCH | sed -e 's|^origin/||')"
    sonar_args=("-Dsonar.branch.name=$branch")
fi

# This assumes the url is in this format: https://github.com/<org>/<repo>.git
org="$(cut -d/ -f4 <<< "$GIT_URL")"
repo="$(cut -d/ -f5 <<< "$GIT_URL")"
export SONAR_ORGANIZATION="${org}"
export SONAR_PROJECT_KEY="${org}_${repo%.git}"

echo "GIT_URL: ${GIT_URL}"
echo "SONAR_ORGANIZATION: ${SONAR_ORGANIZATION}"
echo "SONAR_PROJECT_KEY: ${SONAR_PROJECT_KEY}"

export SONAR_SCANNER_OPTS='-Xms250m -Xmx250m -XX:+UseG1GC -XX:+CMSClassUnloadingEnabled -XX:+UseCompressedClassPointers -XshowSettings:vm'
sonar-scanner "${sonar_args[@]}"

This approach allows us to create new repos with sonar support with minimal manual tuning.

5 Likes
7

We have a strong preference for configuration-as-code and for that we use terraform (https://www.terraform.io/) with a 3rd party terraform sonarqube provider.

This makes it easy to stand up a new instance of Sonar e.g. for testing changes to config, for testing new versions of Sonar etc.

(Side note: Unfortunately SonarQube are making this approach harder by “magically” creating resources that the tooling cannot be aware of - e.g the recent change to add conditions to newly created quality gates automatically)

We also have a strong preference for global or project-level configuration over configuring at analysis time so we can up-front configure the tooling rather than waiting until analysis (or post-analysis) time.
There is nothing we want to configure at analysis time other than branch/PR specific info like version number, base branch etc.

It would be great if all “project level” settings (e.g. well known hyperlinks, project names/descriptions) could be set/changed actually on a project and not when an analysis is done on the main/master branch - which makes no real sense IMO.

It would also be great if we could configure “new code” policies without branches having to exist already.

The current mechanism makes it very hard to automate creation of SonarQube project configured as we want them configured because we have to set up the initial project, then run an analysis to get some more properties set AND run analyses per branch we want to set a new code policy on and then go set the actual new code policy.
This can be a drawn-out and quite painful process if for example we have a brand new project and we need to add it to Sonar and configure the new code policy for the prod branch - this branch may not exist for months whilst the code is in development - we want the code to be written cleanly so we want to configure it in Sonar asap…it is tediious, manual, prone to forgetting to have to come back to it again later once the prod branch actually exists.

1 Like