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 8192My repo is in gitlab And Github from
docker-compose.ymlfiles. 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 shelfsonarqube/logslogs of web processes, services that Sonar usessonarqube/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:
Link Gitlab and Sonarqube using the user’s Access token.
Check that it is possible to initialize the analysis of repositories (their list appears after you add a project in the main menu:
Select a repository and click “Set Up”
Then choose your CI/CD system and follow the instructions.
Create the sonar-project.properties file in the repository. Specifying the key and parameter that monitors communication with Sonarqube.
Add two environment variables: SONAR_TOKEN And SONAR_HOST_URL
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.
First, in the same place you need to add a project. Only now we need a button Manually
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.
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
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.
config | Description |
| Unique key for the project, wound up in Sonarqube |
| Display name of the project in the interface |
| The version of the project you specify |
| Project Description |
| Specifying the path to files for analysis |
| Specifying the path to the files to be excluded for analysis |
| Encoding for the project, usually UTF-8 |
| The URL of Sonarqube itself. The default is localhost:9000. |
| Default project directory |
| For Java projects, the path to the binaries |
| Either true or false. Rule to allow scanning of uncompiled code |
| Checking the availability of Sonar, if unavailable – a failure of the work / pipeline |
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-Kxp5QiICAnd 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: manualFor 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 🙂
