Реализация потока CI/CD с помощью Gradle, Jenkins и Sonar

Question

Итак, в настоящее время я пытаюсь реализовать рабочий процесс CI/CD для моего проекта, который будет выпущен для общественности. Потому что то, что я выпускаю, является скорее каркасом, я признаю, что люди возьмут мой код, изменят его, как они сочтут нужным, и сами сделают свои изменения (если они захотят). Поэтому я не хочу ничего налагать на их процесс сборки (т. Е. Правила checkstyle, ненужные зависимости и т. Д.).

Так что путь I (лично) решил написать фреймворк, чтобы использовать Gradle для построения, а также для фиксации, начать сборку Jenkins, которая будет запускать все модульные тесты, выполнять статический анализ, а затем упаковывать необходимые файлы в формате, который люди могут загрузить.

1. Написать код
2. Run Local Unit Tests
3. Commit Code
4. Стартовое Дженкинс Построить
5. Run Unit Tests
6. Run Интеграционные тесты
7. Выполнить анализ на результат
8. Загрузить анализ на сервер SonarQube
9. Возьмите файлы сборки и пакет в двоичные и исходные версии.

Моя проблема, однако, в том, что я не могу настроить аспект Сонара в Дженкинсе. Как я уже сказал, я не хочу навязывать свои правила чужому процессу, поэтому я отделил функциональность как шаг Дженкинса. Однако, если я выполнил шаг сонара, он полностью исключит аспект модуля тестирования. Я не могу определить причину. Однако, если я модифицировать Gradle файл включить

apply plugin: 'sonar-runner' 

и добавьте Invoke Gradle Task шаг вместо задачи эхолота, она отлично работает.

Я иду об этом неправильно? Если я включу эту часть в файл Gradle, я получу то, что мне нужно, но я навязываю требование Gradle о том, кто загружает мой код (возможно, используя Maven вместо этого). Есть ли способ обойти это?

Answer 1

Вы не «навязываете» что угодно, включив плагин сонара в сценарий сборки Gradle. Разработчик не обязан запускать задачи сонара для создания вашего проекта, и пока любая необходимая конфигурация, необходимая для настройки сонара, не разрушает сборку, если она отсутствует, я бы сказал, что вам хорошо идти.

Это не редкость для создания проектов с открытым исходным кодом, содержащих логику, специфичную для выпуска или развертывания. Это нормально, если: a) выполнение этих задач за пределами выделенной среды CI завершается с ошибкой (как правило, из-за отсутствия разрешения на загрузку для выпуска репо), и b) разработчики все еще могут создавать/тестировать, не выполняя эти задачи.

В целом, я думаю, что ваш последний подход лучше, поскольку теперь у вас меньше зависимости от конкретной инфраструктуры CI, что облегчит миграцию.