Simple Use Cases for Sonarqube

Some information about Sonar

To date, this is one of, or the most well-known method of automatic code analysis and review. It owes its popularity to the fact that this service is free and available, and it does not require much effort to install it. The interface looks modern and clear. Sonarqube, although written in java, doesn’t eat a lot of resources 🙂

Publication content:

• Service deployment with docker-compose

• Some easy ways to parse repositories

• Contents of sonar-project.properties

• Examples, integrations with CI/CD systems

“Program testing can be quite effective in demonstrating the presence of bugs, but is hopelessly inadequate in demonstrating their absence.”

Edsger Wiebe Dijkstra

Sonarqube Deploy

The easiest and most popular way to work with such services is to find an image on dockerhub and deploy using a docker-compose file. Link to his image.
But here lies the nuance – Docker Host Requirements, since sonarqube uses the built-in Elasticsearch and for the service to work correctly, the specified system limits are required:

sysctl -w vm.max_map_count=524288
sysctl -w fs.file-max=131072
ulimit -n 131072
ulimit -u 8192

My repo is in gitlab And Github from docker-compose.yml files. IN Makefile there is a single instruction for these commands.

Purpose volumes:

• sonarqube/datadata files, elastic indexes and some other things that Sonar would like to keep on the shelf

• sonarqube/logslogs of web processes, services that Sonar uses

• sonarqube/extensionsfor native plugins (which contain parsing rules for all languages)

Out of the box, it already has enough plugins for analysis, but if you find something custom or made it yourself, adding it is quite simple – just put it in volume with extensions.

I talk about the installation in more detail in the video – Getting started with Sonarqube.

In the video, I show you how to connect Sonar to Gitlab to analyze projects from there. Along with this, you can configure the ability to log in to Sonar using Gitlab accounts.

Keep in mind that it’s good practice to create a Gitlab account for Sonarqube, and take the access token from there, so that if you have problems with your own record, you won’t lose the accumulated analysis and don’t set everything up again. But it will always be necessary to add this user to projects, and give rights no lower than Reporter.

Easy Ways to Analyze Projects

Project from Gitlab

Who is more comfortable with the visual presentation of information – below is a video on this topic. You can also look at link.

Translating to the text, I can say that all you need is:

1. Link Gitlab and Sonarqube using the user’s Access token.

2. Check that it is possible to initialize the analysis of repositories (their list appears after you add a project in the main menu:

3. Select a repository and click “Set Up”

4. Then choose your CI/CD system and follow the instructions.

3. Create the sonar-project.properties file in the repository. Specifying the key and parameter that monitors communication with Sonarqube.

   

4. Add two environment variables: SONAR_TOKEN And SONAR_HOST_URL

5. Last step: include the stage file with the scan in the CI

Manual addition of any project

Here everything is according to a similar scenario, the file plays the greatest role sonar-project.properties.

1. First, in the same place you need to add a project. Only now we need a button Manually

   

2. After that, you need to create project key (unique project ID) And display name (the name for the project to be displayed in the list). They may be different.

3. Next, you need to create an access token, and name it as you need, it will also be displayed in your user profile and you can delete it only from there

   

4. The next step is to select a stack/script to analyze and follow the instructions. At the end, you will be presented with data for the properties file of the project, or commands for manually launching the scan.

   

Components of the sonar-project.properties file

The file from which Sonarqube draws instructions for its operation. The most complete description of possible configs for the project in documentation to the service. Here is a small table with the most common ones.

Examples, integrations with CI/CD systems

For Gitlab CIyou can add a stage with Sonar analysis of the project, it looks like this:

stages:
  - sonar-scan


sonarqube-check:
  stage: sonar-scan
  image:
    name: sonarsource/sonar-scanner-cli:latest
    entrypoint: [""]
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
    GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script:
    - sonar-scanner

Job executes the sonar-scanner command, which accesses the sonar-project.properties file and follows its instructions. At the end of the Job, the report is compressed and sent to UI Sonarqube. If you follow the instructions for Gitlab, do not forget to add environment variables with the URL and the token.

How about in Jenkins?

Similar to Gitlab, only with its own syntax. We create a Job, add a token, pull a repository from Git, in which we previously added the sonar-project.properties file with the projectKey specified:

sonar.projectKey=r1645_django_ruscon_global_AX8Y7oucXjz-Kxp5QiIC

And add this stage:

node {
  stage('SCM') {
    checkout scm
  }
  stage('SonarQube Analysis') {
    def scannerHome = tool 'SonarScanner';
    withSonarQubeEnv() {
      sh "${scannerHome}/bin/sonar-scanner"
    }
  }
}

All detailed instructions are provided by the service itself.

In this video I show how to work with Java and Gradle and how to configure Jenkins for daily project scanning

From my point of view, the most pleasant use casethis is the daily scan of the master branch( master, dev, main) through Jenkins, the branch into which your automerges go and you merge the code ready to run. As well as automatic scanning of release branches using Gitlab CI. To do this, just add the following rule:

rules:
  - if: $CI_COMMIT_REF_NAME =~ /^release/
    when: always
  - if: $CI_COMMIT_REF_NAME != /^release/
    when: manual

For all other branches – manual start of the analysis.

At this point, the article ends. I want to remind you that the methods I have listed claim to be a 100% professional approach, I will be glad for feedback and possibly your advice on work, additions to what was written. These are just my ways of routinely using this service that I wanted to share with you.

Thank you very much for reading or watching the video 🙂