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

Немного информации о 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

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

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

1. Связать Gitlab и Sonarqube, с помощью Access token пользователя.

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

3. Выбрать репозиторий и нажать «Set Up»

4. Далее выбрать свою CI/CD систему и действовать по инструкции.

3. Создать в репозитории файл sonar-project.properties. С указанием ключа и параметра, мониторящего связь с Sonarqube.

   

4. Добавить две переменные окружения: SONAR_TOKEN и SONAR_HOST_URL

5. Последний шаг: включить в CI файл stage со сканом

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

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

1. Для начала, в том же месте нужно добавить проект. Только теперь нам нужна кнопка Manually

   

2. После этого необходимо создать ProjectKey (уникальный идентификатор проекта) и DisplayName (имя для проекта , которое будет отображаться в списке). Они могут быть разные.

3. Далее нужно создать токен доступа, и назвать его так как вам нужно, он так же будет отображаться в профиле вашего пользователя и удалить его можно будет только оттуда

   

4. Следующий шаг — выбрать стэк/сценарий для анализа,и следовать инструкции. В конце для вас будут представлены данные для properties файла проекта,либо команды для ручного запуска скана.

   

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

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

Примеры, интеграции с 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% проффесиональный подход, буду рад фидбэку и возможно вашим советам по работе, дополнениям к написанному. Это всего лишь мои способы рутинного пользования этим сервисом, которыми я захотел поделиться с вами.

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