Gitea и SonarQube: как подружить лёгкий Git-сервер с анализом кода

Self-hosted инфраструктура — это всегда компромисс. Хочешь контроль — получаешь головную боль с настройкой. Gitea в этом плане радует: поставил, настроил, забыл. Но когда речь заходит о качестве кода, встроенных инструментов не хватает. SonarQube — классическое решение. Вопрос в том, как их связать без боли.

Давайте разберёмся, стоит ли игра свеч, какие есть подводные камни и какие альтернативы существуют.

Что за связка и зачем она нужна

Gitea — это легковесный Git-сервер, написанный на Go. Форк Gogs, который активно развивается. Минимальные требования к ресурсам, ставится хоть на Raspberry Pi. Многие команды выбирают его именно за простоту: один бинарник, SQLite по умолчанию, готово.

SonarQube — платформа для статического анализа кода. Находит баги, уязвимости, code smells, считает технический долг. Enterprise-решение с соответствующей мощью и соответствующими требованиями.

Проблема в том, что Gitea не умеет нативно интегрироваться с SonarQube. В отличие от GitLab CI или GitHub Actions, здесь нет готовых кнопок «подключить SonarQube». Придётся строить велосипед.

На одном проекте мы потратили два дня на настройку этой связки. И это при том, что оба инструмента уже были развёрнуты. Если считать с нуля — неделя минимум.

Как это настраивается

Есть два основных пути: Drone CI или внешний CI-сервер. Рассмотрим оба.

Вариант с Drone CI

Drone — CI/CD-система, которая идеально ложится на философию Gitea. Контейнеры, YAML-конфиги, минимум магии.

# .drone.yml
kind: pipeline
type: docker
name: default

steps:
  - name: sonar-scanner
    image: sonarsource/sonar-scanner-cli
    environment:
      SONAR_HOST: http://sonarqube:9000
      SONAR_TOKEN:
        from_secret: sonar_token
    commands:
      - sonar-scanner \
          -Dsonar.projectKey=my-project \
          -Dsonar.sources=. \
          -Dsonar.host.url=$SONAR_HOST \
          -Dsonar.login=$SONAR_TOKEN

Выглядит просто. Но есть нюансы. SonarQube должен быть доступен из контейнера Drone. Token нужно пробросить через секреты. Проект нужно создать в SonarQube заранее или автоматизировать это через API.

Вариант с Jenkins

Если у вас уже есть Jenkins — можно использовать его. Gitea поддерживает webhooks, Jenkins умеет их слушать.

pipeline {
    agent any
    stages {
        stage('SonarQube Analysis') {
            steps {
                withSonarQubeEnv('my-sonar') {
                    sh 'sonar-scanner'
                }
            }
        }
    }
}

Jenkins мощнее, но тяжелее. Для маленькой команды — избыточно. Для большой — придётся настраивать распределённые билды, и это уже совсем другая история.

Что получается в итоге

Если всё настроено правильно, пайплайн выглядит так: push в репозиторий → webhook → CI запускает анализ → SonarQube показывает результат. Можно настроить quality gates — если код не проходит, MR не мержится.

Но тут начинаются проблемы.

SonarQube требует ресурсы. Elasticsearch жрёт память. Для production-инсталляции рекомендуют минимум 2 GB RAM только под SonarQube. Gitea при этом работает на 512 MB. Дисбаланс очевидный.

Обновления — отдельная боль. SonarQube любит ломать обратную совместимость плагинов. Обновил версию — переписывай конфиги. Gitea обновляется легко, но интеграция может отвалиться.

По моему опыту, большинство команд, которые попробовали эту связку, либо смирились с костылями, либо ушли на GitLab. Там SonarQube интегрируется через плагин, и всё работает из коробки.

Честное сравнение

Стоит пояснить про Russian compliance. Если вы работаете с персональными данными или гостайной, SonarQube на зарубежных серверах — это риск. Либо разворачивайте свой инстанс, либо ищите альтернативы.

Для кого подходит связка Gitea + SonarQube

Идеальный кейс: команда из 5-20 человек, уже использует self-hosted инфраструктуру, есть выделенный сервер под SonarQube, есть время на настройку и поддержку.

Если вы стартап или маленькая команда без DevOps-инженера — это оверхед. Проще взять готовое решение.

Если у вас микросервисная архитектура на 50+ репозиториев — SonarQube справится, но настройка quality gates для каждого проекта превратится в ад.

Если важна скорость — анализ на большом проекте может идти 10-15 минут. Для сравнения: инкрементальный анализ в Distiq отрабатывает за секунды, потому что работает по-другому.

Альтернативы

SonarCloud — SaaS-версия SonarQube. Работает с GitHub, GitLab, Bitbucket. С Gitea — только через костыли с webhook'ами. Плюс данные уходят в облако, что не всем подходит.

CodeClimate — хороший вариант для Ruby и JavaScript. Но языковая поддержка ограничена, и снова SaaS.

На одном проекте мы внедряли связку Gitea + SonarQube, потому что так сказал CISO. Через полёт переключились на Distiq — меньше головной боли, а результат тот же: баги находятся, стиль проверяется, команда довольна. Distiq интегрируется через webhook за пару минут, серверы в РФ, и не надо думать о ресурсах для SonarQube.

Итог

Gitea + SonarQube — рабочая связка, но требует усилий. Если у вас уже есть инфраструктура и люди, которые её поддерживают — почему бы и нет. Если хочется быстро и без боли — посмотрите в сторону Distiq. Он умеет то же самое: анализ кода, поиск багов, проверка стиля. Но без необходимости разворачивать и поддерживать SonarQube.