Как я могу сохранить предупреждения компилятора в Hudson (CI) при использовании SVN Update?

Question

У меня есть непрерывная настройка интеграции с использованием Hudson, и в последнее время я настроил задания для использования svn update для получения последней версии кода.Мне очень нравится этот подход, так как он позволяет msbuild корректно создавать версии и создавать только собранные сборки.

Однако я заметил, что, поскольку я не собираюсь снова собирать все сборки, я теряю всепредупреждения компилятора для этих сборок, если они не собраны.

Например, если у меня есть 3 сборки с зависимостями, показанными с помощью отступа:

• Сборка 1 10 предупреждений
  • Сборка 2 (зависит от 1) 10 предупреждений
    • Сборка 3 (зависит от 2) 10 предупреждений

Первая сборка будет собирать все 3 сборки и регистрировать 30 предупреждений.

Следующая сборка, если я только изменю сборку 3, Хадсон будет собирать только сборку 3и я получу только 10 предупреждений для этой сборки, фактически помечая 20 предупреждений как «фиксированные».

Насколько я могу судить, никакого пути не будет, но я бы с удовольствиемзнать, если кто-то настроил Гудзон для ретейВ этих предупреждениях компилятора от одной сборки к другой.

Редактировать: Да, я понимаю, что это может перерасти в дискуссию о том, что «вы должны / не должны делать обновление на блоке CI», но есть причинымы пошли с подходом обновления.

• Это примерно в 3 раза быстрее
• Мы по-прежнему производим самые современные сборки
• msbuild может соответствующим образом версиями сборок .

Answer 1

Я бы изменил ваш подход к сборке CI.Инкрементная сборка на сборочной машине очень вводит в заблуждение и имеет только предельное значение (IMHO), и если ваша система не соответствует размеру операционной системы, вы, вероятно, не экономите много времени.

Если у вас есть сборкикоторые не изменяются часто или никогда, упаковывают их как «сторонние» зависимости (возможно, даже в модуле слияния, чтобы ваше развертывание могло легко их подобрать) и не перестраивают их с помощью своего CI.

С другой стороны, если все ваши сборки нестабильны (их нужно перестраивать более одного раза в цикле выпуска), создайте их все время.

Answer 2

Ну, msbuild делает то, что должен: он только регистрирует предупреждения, с которыми он столкнулся.

Если вы должны использовать svn update, единственный способ это сделать:

• анализ журнала сборки и определение того, какие сборки не были собраны
• foreach неотстроенная сборка
  • поиск предупреждений за последний раз, когда была собрана конкретная сборка
  • перенос вручнуюэти предупреждения перешли в текущую сборку.

Это может / не может быть громоздким, и ему нужно было бы иметь приличное понимание формата журнала msbuild.

Можно также утверждать, что это вводит в заблуждение, поскольку вы будете записывать предупреждения, которые не были зарегистрированы для этой конкретной сборки.

Answer 3

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

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

РЕДАКТИРОВАТЬ: Проблемы с версиями

Вы можете настроить Hudson (в связи с SVN) на игнорирование коммитов определенными пользователями. При использовании этого черного списка не должно быть проблем с тем, что msbuild выполняет управление версиями.