2013-08-22 9 views
1

У меня есть профиль качества в Sonar, который будет предупреждать о том, что количество нарушений растет со времени предыдущего анализа, например. «Предупреждение, если критические проблемы, поскольку предыдущий анализ больше 0».Дифференциальные оповещения о сонаре

Проблема в том, что при выполнении последующей сборки без каких-либо изменений кода (или, возможно, безвредного изменения кода) предупреждение очищается.

Есть ли способ собрать результаты для Сонар для сравнения своих результатов против последнего анализа, который не содержит никаких предупреждений?

EDIT: Я должен четко указать, что опция «разница с предыдущей версией» не будет работать для нашей установки, поскольку мы используем стратегию непрерывной доставки, в которой каждая сборка является потенциальным кандидатом на выпуск с собственной уникальной версией (мы используем дату/время в качестве версии).

EDIT # 2: Я также попытался установить значение sonar.timemachine.period4 в твердую кодировку, которую я хочу сравнить; однако это значение недоступно при настройке предупреждений и, безусловно, игнорируется во время фактического анализа.

ответ

1

После того, как я выкрикнул в источнике Sonar, мы с коллегой придумали обходное решение.

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

Для каждой сборки:

  • Запрос последний VCS тег с версией сборки и присвоить его переменной $ {LAST_GOOD_BUILD} или аналогичный для остальной части процесса сборки для использования.
  • Run Sonar с -Dsonar.timemachine.period3=${LAST_GOOD_BUILD} (также убедившись, что плагин BuildBreaker активен)
  • Если вы не получите оповещения, следующий шаг сборки нужно записать новую версию в VCS теге;

Это работает, потому что sonar.timemachine.period3 является тем же самым параметром, что и «предыдущая версия» в вашем профиле качества, но теперь вы заменяете его на твердую версию по вашему выбору. Каждый раз, когда вы создаете, вы помещаете только сборки, которые проходят проверку качества, а когда вы запускаете Sonar, вы сравниваете только эти хорошие версии.

Довольно ужасно, но он снова поднимает трубопровод сборки. Если что-то неясно об этом, сообщите мне, и я обновлю это «решение».

CAVEATS: Ваша нумерация версий не может быть целыми целыми числами. Sonar будет интерпретировать это как количество дней между вашим текущим анализом и тем, с которым вы хотите сравнить! Кроме того, он не может быть в формате, который можно было бы смутить с помощью yyyy-MM-DD (например, 1000-01-01), как если бы это также произошло, чтобы разрешить реальную дату, тогда вы непреднамеренно указываете начало диапазона дат. Я еще не видел, чтобы кто-либо указывал номера версий таким образом, но вы никогда не знаете.

0

Нет, но вы можете настроить SonarQube, чтобы основывать свои дифференциальные представления на previous_version или на дату. См. http://docs.codehaus.org/display/SONAR/Differential+Views#DifferentialViews-DifferentialViewsSettings

+0

Я знаю об этих параметрах, но, к сожалению, они не работают в конвейере сборки компакт-дисков - я обновил свой исходный вопрос соответственно. Если Sonar может отслеживать последний «хороший» анализ (один без каких-либо предупреждений) и использовать его в качестве основы для сравнения, это освободит меня от использования любой стратегии построения/версии, которую я хотел.Прямо сейчас кажется, что мне нужно будет изменить мой строительный трубопровод, чтобы Sonar работал. – RCross

 Смежные вопросы

  • Нет связанных вопросов^_^