This is an internal documentation. There is a good chance you’re looking for something else. See Disclaimer.


SonarQube is a static code analysis tool. It reports common errors and code smells, as well as statistics about a code base. At Tocco, we analyse our backend and frontend code with SonarQube. Our self-hosted instance of SonarQube can be found at For each version we set new targets to reach in our code as a team. These targets can be found in our SharePoint under Technik/Quality Assurance/Sonar.


We run an analysis for each of our codebases each day. We only analyse the current master branch of each codebase. Most Quality Gates are turned off currently. This way SonarQube currently just provides a view of the current state of our code and a history how it developed.


The job and schedule can be found at See the root build.gradle for the SonarQube configurations used. The project in SonarQube is called Nice2 Backend and can be found at


The schedule can be found at See the .gitlab-ci.yml file for the CI job and the file for the SonarQube configurations. The project in SonarQube is called Nice2 Client and can be found at

User Accounts

To access SonarQube, you need a user account. At time of writing, we have no automated process to create user accounts, so you will have to create your own. The password for the admin account can be found in secrets2.yml. Create a new user account under and feel free to give yourself admin rights. Please do not continue to use the admin account for yourself, since we would like to know who changed what and be able to assign issues.


A companion plugin to SonarQube is available for many different editors, including Jetbrains IDEs and VSCode. It can be used in standalone mode, in which it simply informs you about errors and code smells as you have configured it, or in connection with our SonarQube instance. When connected to our instance, it will check our settings and report problems in-line with how we have configured them.

Dealing with issues

There are several different ways how to handle issues.

Fix them

The easiest is to simply fix them. Read their description and adjust the affected code like you would any other task.

Ignore them

Some issues are false positives, others we can’t or don’t want to fix. These issues can be marked as such directly in SonarQube. Previously, we would use annotations and comments in the code itself to mark these issues. This is something we want to get away from and you are welcome to remove any such markings when you encounter them.

Remove them

The rules SonarQube uses to create issues are configurable and have in fact been heavily adjusted by us already. If a rule does not make sense in your opinion start a discussion with the developer. If a consensus is reached the rule can be deactivated in SonarQube itself. Check the documentation or ask someone else about how to deactivate the rule.