SonarQube

Last modified by Jukka Karvonen on 2025/03/28 16:46

SonarQube is a tool for static code analysis that aims to detect potential issues and guide development towards the Clean Code  principles defined by Sonar.

  • Supports multiple programming languages
  • Aims to identify issues in the code based on various rules, including:
    • Security-related potential problems or vulnerabilities.
    • Reliability-related bugs and issues.
    • Maintainability-related issues.
  • Provides a clear report of findings and allows for the handling of isssues within the service.
  • Also evaluates test coverage, duplicate code, and provides a rating for different areas based on goals set for the project (Quality Gate).

sonarqube.it.helsinki.fi

The IT Center maintains a SonarQube environment based on the open-source community version at https://sonarqube.it.helsinki.fi.

Since it is a free community version, it does not support separate analysis of different code branches.

  • This may cause some issues in defining and analyzing "new code" when PRs are submitted by different users at the same time.
  • Consider appropriate practices for the project and explore using SonarLint (mentioned at the end of the page), which allows analysis directly in your own IDE.

Usage Principles

  • The service is provided as is, largely with SonarQube's default settings and relatively low priority.
    • The service aims to be available and updated to the latest version of SonarQube.
  • Any logged-in user (HY SSO) can create new projects.
    • Projects must be related to the University of Helsinki.
    • The IT Center reserves the right to remove projects that have not been changed in the past 12 months.
  • Project permissions can be managed based on IAM groups.
    • Groups must first be created in SonarQube, after which membership information updates upon login.
    • Groups can also be given the right to define team-specific Quality Profile/Quality Gate settings.
      • These settings are public and should be named in the format "<unit>-<group>-<name, e.g., project>", such as "Tike-Ohtu-Ryhti".
      • Default settings in SonarQube (Sonar way) SHALL NOT be altered.
    • The project founder is responsible for the project's permissions.
    • For creating groups or defining permissions, contact tike-ohjelmistotuotanto@helsinki.fi

Adding a project to SonarQube

  1. Log in to the service.
  2. Select Projects → Create Project
    1. Select From GitLab to import project from the version.helsinki.fi, using personal access token with read permissions OR
    2. Select Local project to enter project details manually.
  3. Select how new code is defined (a link on the page provides descriptions of different options)
    1. Note that the community version in use does not support branch-level analysis.
  4. Projects are created public by default (setting was changed).
    1. If you wish to allow all users to see code and observations, change it to public: Select Project Settings → Permissions. From the top, select Public or Private.
    2. The project founder automatically receives all rights to the project.
    3. You can define rights for either a user group (IAM group, see creation note in Usage Principles) or individual users.
  5. The Overview tab provides instructions on how to send code for analysis.
    1. Options include the SonarScanner application from the command line or integrating analysis directly into a GitLab CI or Github Actions pipeline.

Project-Specific Analysis

Rules SonarQube reporting is based on Quality Gates and Quality Profiles settings.

Quality Gates

Quality Gates define the conditions under which new code passes the inspection. This can be evaluated using parameters such as (default in parentheses):

  • Number of issues (none).
  • Number of security hotspots (all must be reviewed).
  • Test coverage (80%).
  • Code duplication (3%).

Default settings are the result of SonarQube's long experience and statistics. It is advisable to read about the Clean as You Code principles before making modifications.

Quality Profiles

Quality Profiles define language-specific inspection rules and the severity of the findings they raise.

Changing settings

Projects can set custom Quality Gates and Profiles.

All Quality Gates and Profiles are public, and their creation requires specific rights. See the Usage Principles section for instructions on obtaining rights.

  • This ensures that those with modification rights have read these instructions and do not modify others' rules. Authorized individuals can create new rules from the Quality Profiles/Quality Gates menu at the top.
  • It is advisable to copy an old rule as a basis for the new one.
  • Name your own rules in the format "<unit>-<group>-<name, e.g., project>", such as "Tike-Ohtu-Ryhti". Rules named otherwise will be removed.

Change the desired rule for the project from Project Settings → Quality Profiles/Quality Gates.

Instructions and documentation

SonarQube help site: https://docs.sonarsource.com/sonarqube/latest

Examples for GitLab CI integration: SonarQube GitLab CI

SonarLint

SonarLint is an analyzer integrated directly into the IDE, evaluating the same aspects as SonarQube and can be directly linked to a SonarQube project.

  • Free add-on with support for multiple IDEs (VS Studio/Code, Eclipse, JetBrains products such as IntelliJ IDEA, and PyCharm).
  • Check support for your IDE and see installation instructions at https://www.sonarsource.com/products/sonarlint/
  • You can link SonarLint directly to your SonarQube project, using the analysis settings defined in the project.