Может ли maven-sonar-plugin провести локальный анализ?

Я настраиваю многомодульный проект maven, который вызывает выполнение sonar:sonar на этапе verify.

Я также использую подключаемый модуль сонара build-breaker, чтобы избежать развертывания модуля, если сонар выдает какие-то предупреждения.

Проблема с этим подходом заключается в том, что разработчик должен обращаться к серверу сонара для проверки предупреждений. Это не так уж и плохо, но если несколько пользователей пытаются анализировать один и тот же модуль одновременно, невозможно узнать, есть ли у последнего/текущего анализа ваши предупреждения.

КОНТЕКСТ: у нас есть система непрерывной интеграции, которая создает все модули каждый час. Так что иногда это сталкивается с деплоем разработчика (что приводит к анализу)

ИМХО, только система CI должна передавать анализ на сервер сонара, потому что CI имеет последний зафиксированный и развернутый код. Но разработчик должен только локально проверять свои изменения.

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

Есть ли способ настроить плагин maven-sonar для этого?

  • локальный анализ в девелоперской сборке.
  • анализ сервера в сборке CI

maven sonarqube
person ggarciao    schedule 30.05.2012    source источник
comment
Непонятно, почему разработчикам разрешено deploy modules, а не только CI. Возможно, вы хотите, чтобы разработчики не check-in код, который может сломать сонар?   -  person Raghuram    schedule 30.05.2012
comment
Я согласен с вами, но в конце та же проблема: мне нужно запустить локальный анализ перед scm:checkin. Контекст: Разработчики несут ответственность за некоторые модули, поэтому им разрешено развертывать СНАПШОТЫ. CI предназначен для проверки правильности интеграции всех развернутых модулей (сборка и выполнение интеграционного теста).   -  person ggarciao    schedule 30.05.2012
comment
Удалось ли вам добиться того, чего вы хотели? Вы случайно не сталкивались с этой проблемой? stackoverflow.com/questions/29099614/   -  person Zhenya    schedule 18.03.2015

Ответы (1)


arrow_upward
1
arrow_downward

Насколько я понимаю, у вас, вероятно, должен быть первый экземпляр Sonar, который используется только во время сборки, чтобы сломать его, если ваши требования к качеству не выполняются, и второй, который используется вашей системой CI и является эталоном для вашего продукты. И если вы действительно хотите усилить свой процесс и быть уверенным, что код, нарушающий эти требования, не попадет в вашу систему SCM, тогда вы можете привязать анализ Sonar к крючку перед фиксацией. Но мне это кажется экстремальным...

В SonarSource мы не выбрали подход «заблокировать фиксацию из-за нарушений». На самом деле, мы считаем, что иметь некоторый технический долг (= нарушения) — это нормально, если вы с ним справляетесь. Управление техническим долгом означает просмотр каждого входящего нарушения в Sonar и исправление их в коде или внесение этих нарушений в планы действий, основная идея заключается в том, что технический долг не должен увеличиваться в конце спринта разработки. Именно для этого предназначена функция обзора Sonar. А Sonar предоставляет виджеты для отслеживания эволюции обзоров и новых нарушений без обзора.

person Fabrice - SonarSource Team    schedule 30.05.2012
comment
Я согласен с вами, но я думаю, что некоторые пороги важны! Например: мы не разрешаем публичный API без комментариев (и это не подлежит обсуждению). Хук перед фиксацией — хорошая идея, но мы думаем, что код может быть зарегистрирован в SCM, даже если он плохой, чего мы не можем позволить, так это поделиться этим кодом. Таким образом, мы не разрешаем развертывание SNAPSHOT или RELEASE, которые не соблюдают политику качества кода. Мне нравится ваша идея о двух экземплярах SONAR... есть ли способ синхронизировать правила между ними? - person ggarciao; 30.05.2012
comment
@ggarciao. Вы можете предотвратить совместное использование двоичных файлов, запретив deploy из SNAPSHOTS, но после committed источником все равно будет shared. - person Raghuram; 30.05.2012
comment
@ggarciao К сожалению, нет (для синхронизации правил), вам придется обрабатывать это вручную (с помощью функции экспорта). - person Fabrice - SonarSource Team; 30.05.2012
comment
@Raghuram Код не распределяется между модулями, и у каждого модуля есть свои разработчики. Это похоже на то, что проекты с открытым исходным кодом сотрудничают: у каждого свой жизненный цикл, и они разделяют функции только через СНИМКИ или РЕЛИЗЫ. Проблема здесь может заключаться в модуле имени, который maven использует для агрегации проектов. Итак, пожалуйста, забудьте, что это многомодульный проект: у меня многопроектная среда, и мне нужен суперпроект, который проверяет, что все они могут работать вместе. - person ggarciao; 30.05.2012
comment
@Fabrice - команда Sonar. Я использую вашу стратегию, и она решила мою проблему. Но я думаю, что плагин maven-sonar-plugin должен иметь опцию локального анализа (например, плагин Sonar Eclipse)... что вы думаете? - person ggarciao; 30.05.2012
comment
@Raghuram Это действительно может быть функция будущего. Рад, что вам удалось решить вашу проблему :-) - person Fabrice - SonarSource Team; 30.05.2012
comment
@Fabrice-SonarTeam Где ссылка на билет? :-) - person ggarciao; 01.06.2012