Немного информации о Sonar

На сегодняшний день это один из, или же самый известный способ автоматического анализа кода и его ревью. Популярностью он обязан тому, что этот сервис бесплатен и доступен, а так же для его установки не требуется много усилий. Интерфейс выглядит современно и понятно. Sonarqube, хоть и написан на java, не ест много ресурсов :)

Содержание публикации:

Деплой сервиса с docker-compose
Несколько простых способов анализа репозиториев
Содержание sonar-project.properties
Примеры, интеграции с CI/CD системами

"Тестирование программы может весьма эффективно продемонстрировать наличие ошибок, но безнадежно неадекватно для демонстрации их отсутствия."
Эдсгер Вибе Дейкстра

Sonarqube Deploy

Самый простой и популярный способ работы с таким сервисами - найти образ на dockerhub и задеплоить с помощью docker-compose файла. Линк на его образ.
Но тут же кроется нюанс - Docker Host Requirements, так как sonarqube использует встроенный Elasticsearch и для корректной работы сервиса, необходимы указанные границы системных лимитов:

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

Мой репо в Gitlab и Github с docker-compose.yml файлами. В Makefile есть единая инструкция для этих команд.

Назначение volumes:

sonarqube/data, файлы с данными, тут лежат индексы эластика и еще некоторые вещи, которые Sonar хотел бы держать у себя на полке
sonarqube/logs, логи веб процессов, сервисов которые использует Sonar
sonarqube/extensions, для собственных плагинов (которые содержат правила анализа для всех языков)

Из коробки он имеет уже достаточно плагинов для анализа, но если вы нашли что-то кастомное или сделали сами , добавить это достаточно просто - просто поместить в volume с extensions.

Более подробно об установке я рассказываю в видео - Начало работы с Sonarqube.

В видео, я показываю, как сконнектить Sonar с Gitlab, для анализа проектов оттуда. Вместе с этим можно настроить возможность авторизоваться в Sonar используя учетные записи Gitlab.
Необходимо помнить о том, что хорошей практикой завести в Gitlab учетную запись для Sonarqube, и брать токен доступа оттуда, дабы при возникновении проблем с вашей собственной записью не потерять накопленный анализ и не настраивать все заново. Но всегда необходимо будет добавлять этого пользователя в проекты, и давать права не ниже Reporter.

Простые способы анализа проектов

Проект из Gitlab

Кому удобнее визуальная подача информации - ниже видео на эту тему. Посмотреть так же можно по ссылке.

Переводя на текст, могу сказать,что все что вам необходимо это:

Связать Gitlab и Sonarqube, с помощью Access token пользователя.
Проверить, что есть возможность инициализировать анализ репозиториев (появляется их список после того, как вы в главном меню вы добавляйте проект:

Выбрать репозиторий и нажать "Set Up"
Далее выбрать свою CI/CD систему и действовать по инструкции.

Создать в репозитории файл sonar-project.properties. С указанием ключа и параметра, мониторящего связь с Sonarqube.
Добавить две переменные окружения: SONAR_TOKEN и SONAR_HOST_URL
Последний шаг: включить в CI файл stage со сканом

Мануальное добавление любого проекта

Здесь все по схожему сценарию, наибольшую роль играет файл sonar-project.properties.

Для начала, в том же месте нужно добавить проект. Только теперь нам нужна кнопка Manually
После этого необходимо создать ProjectKey (уникальный идентификатор проекта) и DisplayName (имя для проекта , которое будет отображаться в списке). Они могут быть разные.
Далее нужно создать токен доступа, и назвать его так как вам нужно, он так же будет отображаться в профиле вашего пользователя и удалить его можно будет только оттуда
Следующий шаг - выбрать стэк/сценарий для анализа,и следовать инструкции. В конце для вас будут представлены данные для properties файла проекта,либо команды для ручного запуска скана.

Составляющие sonar-project.properties файла

Файл из которого Sonarqube черпает инструкции для его работы. Самое полное описание возможных конфигов для проекта в докуметации к сервису. Привожу небольшую табличку с наиболее часто встречающимися.

Конфиг	Описание
`sonar.projectKey`	Уникальный ключ для проекта, заведенный в Sonarqube
`sonar.projectName`	Отображаемое имя проекта в интерфейсе
`sonar.projectVersion`	Задаваемая вами версия проекта
`sonar.projectDescription`	Описание проекта
`sonar.sources`	Указание пути к файлам для анализа
`sonar.exclusions`	Указание пути к файлам, которые необходимо исключить для анализа
`sonar.sourceEncoding`	Кодировка для проекта, обычно UTF-8
`sonar.host.url`	URL самого Sonarqube. По дефолту берется localhost:9000.
`sonar.projectBaseDir`	Директория проекта по умолчанию
`sonar.java.binaries`	Для Java проектов, путь к бинарникам
`sonar.findbugs.allowuncompiledcode`	Либо true, либо false. Правило для разрешения скана не скомпллированого кода
`sonar.qualitygate.wait`	Проверка доступности Sonar, при недоступность - сбой работы/пайплайна

Примеры, интеграции с CI/CD системами

Для Gitlab CI, можно добавить stage с анализом Sonar-ом проекта, выглядит он вот так:

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 выполняет команду sonar-scanner , которая обращается к файлу sonar-project.properties и следует его инструкциям. В конце Job-a сжимается отчет и отправляется в UI Sonarqube. Если идти по инструкции для Gitlab не забыть добавить переменные окружения с URL и токеном.

А как в Jenkins?

Аналогично Gitlab, только со своим синтаксом.Создаем Job, добавляем токен, вытягиваем из Git репозиторий, в котором предварительно добавили файл sonar-project.properties с указанием projectKey:

sonar.projectKey=r1645_django_ruscon_global_AX8Y7oucXjz-Kxp5QiIC

И добавляем вот такой stage:

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

Все подробные инструкции предоставляются самим сервисом.

В этом видео я показываю как работать с Java и Gradle и как конфигурировать Jenkins для ежедневного скана проектов

С моей точки зрения, наиболее приятный кейс использования, это - ежедневный скан главной ветки( master, dev, main) через Jenkins, той ветки в которую идут ваши автомержи и вы сливайте готовый к запуску код. А так же автоматический скан релизных веток с помощью Gitlab CI. Для этого достаточно добавить вот такое правило:

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

Для всех остальных веток - ручной запуск анализа.

На этом моменте статья заканчивается. Хочу напомнить, что перечисленные мной способы претендуют на 100% проффесиональный подход, буду рад фидбэку и возможно вашим советам по работе, дополнениям к написанному. Это всего лишь мои способы рутинного пользования этим сервисом, которыми я захотел поделиться с вами.

Большое спасибо, что дочитали или посмотрели видео:)

Простые сценарии использования Sonarqube