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

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

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

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

  • Assembly 1 10 warnings
    • Assembly 2 (Depends on 1) 10 warnings
      • Assembly 3 (Depends on 2) 10 warnings

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

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

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

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


continuous-integration c# compiler-warnings msbuild hudson
person Allen Rice    schedule 14.07.2010    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

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

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

person dkackman    schedule 14.07.2010
comment
Каким образом это вводит в заблуждение? Мой блок CI по-прежнему будет создавать и выпускать самые последние версии сборок. Кроме того, выполнение обновления по сравнению с полной очисткой заняло сборку 50-75 сборок с 15+ минут до в среднем 2-3 минут, так что это того стоит. - person Allen Rice; 14.07.2010
comment
Возможно, я слишком консервативен, но я не доверяю всему, что не является чистой сборкой. Инкрементальные сборки могут скрывать такие тонкие вещи, как введение циклических зависимостей, которые могут нарушить чистую сборку. Но да, 15+ до 2-3 минут меняют уравнение. - person dkackman; 15.07.2010
comment
Я согласен с Дкакманом в отношении доверия, но не обязательно в отношении большого изменения в уравнении. - person Peter Schuetze; 15.07.2010
comment
@dkackman, возможно, я не описал это как следует или как правильно работают инкрементальные сборки. У меня есть решение с 50+ проектами. Msbuild создает решение. Ссылки делаются по проектам (а не по собранной dll). Если изменение зафиксировано в коде любого данного проекта, тогда msbuild достаточно умен, чтобы построить каждую сборку, которая ссылается на измененную. Невозможно (в приведенном выше сценарии) добавить в микс ошибку или циклическую зависимость, которые в противном случае были бы обнаружены полностью чистой сборкой. - person Allen Rice; 15.07.2010
comment
@Allen - При 50+ проектах на решение я бы начал разбивать проекты на более детализированные уровни, где на каждом уровне есть: 1 решение, 1 CI, 1 производственная сборка, 1 модуль слияния (при условии, что вы используете MSI). Мне лично не нравится Единое решение, позволяющее управлять ими и связывать их в темноте, подход к управлению большой системой. - person dkackman; 15.07.2010
comment
В начале 2000-х MSDN рекомендовала этот подход для 75–100 проектов, и это, без сомнения, выросло. Наличие одного решения на проект не обязательно, потому что вы можете указать msbuild как на проекты, так и на решения, чтобы вы могли достичь того же результата с уже существующей инфраструктурой. Вы можете прочитать Решения и проекты по структурированию: msdn.microsoft.com/en- us / library / ee817674.aspx они специально говорят: используйте модель единственного решения, когда это возможно, используйте модель мультирешения, только если это абсолютно необходимо - person Allen Rice; 15.07.2010
comment
О, я не рекомендую одно решение на проект! Я использую 1 решение для каждого слоя / уровня или пакета (пакет представляет собой 1-n сборок, которые тесно связаны между собой по функциям). Я откровенно не согласен с рекомендацией отдать предпочтение одному решению. Это может быть проще в некоторых отношениях, но также подходит для сильно связанной и плохо связной системной архитектуры. Короче говоря, мне нравится, что структура решения отражает архитектуру системы. Если вы купите это, 1 решение подразумевает плохо определенную системную архитектуру. - person dkackman; 15.07.2010
comment
Мы (и MSDN) делаем это для функциональности, а не для простоты использования. Я не вижу, как одно решение приводит к сильной и слабосвязанной системной архитектуре. Это всего лишь инструмент, и то, как вы его спроектируете и будете использовать, определит результат больше, чем ваши инструменты. Может быть, если бы вы предложили преимущество своего пути, вы бы повлияли на меня, но пока вы только сказали, что я не делаю этого таким образом, делая это таким образом, МОЖЕТ привести к xyz. Я могу понять, как вы думаете, что организация ваших решений определенным образом помогает вам сохранять логическое расположение вещей, но это то, для чего нужны папки решений, проекты и пространства имен. - person Allen Rice; 15.07.2010
comment
... продолжение. Честно говоря, когда я думаю об архитектуре и слабой связи, я никогда не говорю: «Черт возьми, если бы у меня было несколько файлов решений, я мог бы иметь гораздо более свободную архитектуру». - person Allen Rice; 15.07.2010
comment
Не существует единого подхода к SCM такого рода, и единое решение может работать и работает. По моему опыту, большие системы с единым решением были монолитными и демонстрировали многие из атрибутов большого шара грязи лапутана. org / mud. Отдельные решения вводят структурное, а не процедурное / традиционное разделение между слоями, что позволяет улучшить изоляцию с течением времени, особенно в отношении раздела выше о разделении слоев. Структурное разделение ставит перед разработчиком препятствие на пути к нарушению архитектуры типов. - person dkackman; 16.07.2010
comment
И причина, по которой я говорю «МОЖЕТ», «ТЕНДОВАТЬ» и тому подобное, заключается в том, что каждая система может начинаться с приличной архитектуры. Подход с использованием единого решения ускоряет разрушение этой архитектуры, которое произойдет, поскольку оно возлагает ответственность за поддержание ограничений на разработчика, а не на структуру системы. (а мы все знаем, что мы, разработчики, ленивые ублюдки :)) - person dkackman; 16.07.2010
comment
PS: это что-то вроде дискуссии в твиттере. Изложите свою точку зрения не более 600 символов. Идти! - person dkackman; 16.07.2010

arrow_upward
0
arrow_downward

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

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

  • проанализировать журнал сборки и определить, какие сборки не были построены
  • foreach unbuilt assembly
    • look up the warnings for the last time that particular assembly was built
    • вручную перенести эти предупреждения в текущую сборку.

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

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

person Allen Rice    schedule 14.07.2010
comment
Просто имейте три отдельных сборки, и у вас всегда будут правильные предупреждения для каждой сборки. - person Peter Schuetze; 15.07.2010
comment
Я честно думал об этом, но не понимаю, насколько это осуществимо в крупномасштабном проекте. - person Allen Rice; 15.07.2010

arrow_upward
0
arrow_downward

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

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

РЕДАКТИРОВАТЬ: проблема с версией

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

person Peter Schuetze    schedule 14.07.2010
comment
Верно, мы делаем сборку обновления по дизайну, потому что нет необходимости перестраивать сборки, которые не изменились. Отдельные разработчики обновляют сборки и завершают перестройки по мере необходимости. Я думаю, вам будет сложно утверждать, что сборки CI не должны быть сборками обновлений (если вы на это ссылаетесь). Кроме того, выполняя обновление, мы позволяем msbuild обрабатывать управление версиями, как описано здесь: stackoverflow.com/questions/1126880/ - person Allen Rice; 14.07.2010
comment
Я отредактировал вопрос, чтобы указать, что эти 3 сборки связаны - person Allen Rice; 14.07.2010
comment
Мое определение связанного заключается в том, что изменение вышестоящего проекта может привести к нарушению сборки последующих проектов. Следовательно, необходима полная сборка. Если это не так, то они независимы. - person Peter Schuetze; 15.07.2010
comment
да, видите, msbuild достаточно умен, чтобы понимать это и, следовательно, строить все последующие проекты ... В моем примере, если я изменил Assembly 2, тогда msbuild построит сборки 2 И 3. Вот почему автоматическое управление версиями (1.0. *) так привлекательно потому что он сохранит неизменные сборки в правильной версии и автоматически увеличит версию для ВСЕХ затронутых сборок. - person Allen Rice; 15.07.2010
comment
Просто ты больше доверяешь технологиям, чем я. ;) - person Peter Schuetze; 15.07.2010