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 https://sonar.tocco.ch. For each version we set new targets to reach in our code as a team. These
targets can be found in our SharePoint under
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 https://tc.tocco.ch/buildConfiguration/Nice2Sonar_Backend. See the root
build.gradle for the SonarQube configurations used. The project in SonarQube is called
Nice2 Backend and can be
found at https://sonar.tocco.ch/dashboard?id=ch.tocco.nice2%3Abackend.
The schedule can be found at https://gitlab.com/toccoag/tocco-client/-/pipeline_schedules/193879/edit. See the
.gitlab-ci.yml file for the CI job and the
sonar.properties file for the SonarQube configurations. The project
in SonarQube is called
Nice2 Client and can be found at
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 https://sonar.tocco.ch/admin/users 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.
The easiest is to simply fix them. Read their description and adjust the affected code like you would any other task.
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.
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.