Может ли TeamCity выполнить вывод одной сборки в другой svn-репозиторий, тем самым начав новую сборку?

До сих пор я использовал TeamCity только как сервер непрерывной сборки. Нет настоящей интеграции. Теперь мне нужно скопировать выходные данные из одного совместно используемого проекта в два других зависимых проекта и начать свою автоматическую сборку по очереди. То есть ProjectA и ProjectB зависят от ProjectC. Все три в настоящее время строятся на TC, когда в своих репозиториях происходит какое-либо фиксация. Мы хотим, чтобы выходные данные ProjectC были скопированы и переданы ProjectA и ProjectB. Такая фиксация, в свою очередь, начнет процесс сборки обоих зависимых проектов. Похоже, что это будет распространенный сценарий, когда речь заходит о непрерывной интеграции. Это не?Может ли TeamCity выполнить вывод одной сборки в другой svn-репозиторий, тем самым начав новую сборку?

Чтобы уточнить, мы используем TeamCity v.4.5.5 (сборка 9103), SVN и nAnt как наш бегун для сборки.

РЕДАКТИРОВАТЬ: Я ошибаюсь, когда я сказал что-то о том, чтобы поступить в другой репозиторий. На самом деле все трое находятся в одном и том же физическом хранилище, на разных уровнях иерархии.

источник

2009-12-09 Kilhoffer

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

Я не знаю, поддерживает ли TeamCity это, но это должно быть легко скомпилировать самостоятельно - в качестве последнего шага сборки в ProjectC добавьте скрипт, который будет проверять директории ProjectC (не весь репозиторий, а только каталог, в котором вы сохранять двоичные файлы ProjectC) из ProjectA и ProjectB, копировать все необходимые файлы и совершать с помощью некоторого автогенерированного сообщения - кажется довольно простым.

Однако - это опасно. Построение ProjectA и ProjectB может сломаться, потому что API ProjectC изменился, или некоторая непроверенная часть кода была нарушена. Это может привести к дезорганизации работы групп A и B. Я бы пошел на решение, когда новая версия библиотек совершается один раз в день/неделю/в любой другой период времени.

Кроме того, было бы неплохо создать автоматический журнал изменений, например, если вы доверяете качеству ваших сообщений журнала svn, вы можете создать журнал изменений из всех «новых» коммитов, включенных в объявленную версию (или добавить текущий сообщение журнала, если вы решили выбрать новые библиотеки после каждого фиксации). Таким образом, команды, отвечающие за ProjectA и ProjectB, смогут легко исправить свою сборку, если новая библиотека сломает ее - они будут точно знать, что было изменено, без необходимости проверять команду вручную/спросить C.

источник

2009-12-09 20:53:25 maciejkow

Отличные советы. Похоже, TeamCity не делает этого напрямую, поэтому сценарий - это то место, где я сейчас. Вы также заставили меня остановиться и подумать о том, хочу ли я, чтобы это произошло после каждой фиксации в ProjectC. Я думаю, вероятно, во время ночной сборки достаточно. Идея автоматического журнала изменений тоже интересна. Никогда не думал об этом. Не уверен, что я доверяю сообщениям журнала достаточно. – Kilhoffer

Обычно вы не делаете вывод сборки в свои репозитории. Вы уверены, что это то, что вы хотите?

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

источник

2009-12-09 18:39:08

В этом случае ProjectC становится третьей стороной ProjectA и ProjectB. Следовательно, его вывод должен существовать в папках «lib» для обоих проектов вместе с другими сторонними сборками. Итак, да, я имею то, что я хочу получить.Использование таких названий, как ProjectA, ProjectB и ProjectC, накладывает пример, но по существу каждый из этих проектов принадлежит различным частям бизнеса и не редактируется друг другом. Поэтому в этом случае желательно, чтобы ProjectC был предоставлен потребителям в формате сборки. – Kilhoffer

В новых версиях TeamCity вы можете определить зависимости артефакта, это позволит вам создать «библиотеку» в соответствии с вашим примером и вытащить артефакты этой сборки в ваши другие проекты. Если вы используете что-то вроде Node.js/npm для создания проекта, вам также понадобится захватить выходную папку (например, «dist»), чтобы при восстановлении артефактов вы могли распаковать одну папку вместо списка зависимостей.

Я могу расширить этот пример, если кто-то заинтересован, просто хотел, чтобы люди узнали об этом через Google, что это намного проще сделать сейчас.

источник

2016-09-20 18:00:14 dragon788

Может ли TeamCity выполнить вывод одной сборки в другой svn-репозиторий, тем самым начав новую сборку?

ответ

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