Меркуриал, субрепозитории и CI

[metaclass]

Достаточно давно не могу придумать, как настроить CI для такой организации нескольких проектов:
1) Есть базовые либы
2) Есть зависящие от них несколько промежуточных проектов (ну типа "общий гуй", "общий веб-сервис")
3) Есть конечные проекты, зависящие от базовых либ и промежуточных проектов.

Каждая группа проектов лежит в своем репозитории, все они являются субрепозиториями для общего репозитория, чтобы "достать все одним hg clone")
И есть желание, чтобы CI собирал таким образом: "при изменении в проекте собирается он и все зависящие от него рекурсивно по зависимостям". Чтобы, например, если коллеги меняют свой конечный проект - пересобирался только он, а остальные проекты не трогались.

Субрепозитории меркуриала хреново ложатся на идею "зависимости между проектами".
Проекты в дотнете можно сделать либо в виде зависимостей-по-исходникам (т.е. все либы включены в .sln файл в виде проектов) или в виде бинарных зависимостей (проекты ссылаются на артефакты билда базовых проектов в виде .dll файлов), первое очень быстро вырождается в sln с 50-100 проектов, второе - в безумное отслеживание зависимостей руками и msbuild скрипты по копированию результатов билда "куда надо".
CI и его триггера для сборки тоже в зависимости умеют непонятно как.

Comments

[vit-r.livejournal.com]

и все зависящие от него рекурсивно по зависимостям

Всё это работает, если изменения делают святые люди, не сажающие в систему новые ошибки. А так, хорошо проверенные вещи внезапно перестают работать.

Единственное, что видел нормального на эту тему, самописанные скрипты, связанные с системой контроля качества. Новые версии библиотек подключаются только по зелёному свистку после полноценной проверки.

[metaclass.livejournal.com]

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

[dr-cha0s.livejournal.com]

я конечно не совсем сварщик... но все зависимости настраиваются в CI, например, jenkins, а не через студию, hg etc...

[metaclass.livejournal.com]

В этом есть зло.
Я пытаюсь сделать такое:
1) Зависимости настраиваются 1 раз
2) Работник одной командой получает на своей машине готовую для работы копию
3) Работник может одной командой собрать полный билд
4) CI использует ту же команду для сборки.

[dr-cha0s.livejournal.com]

зачем 4й пункт? ты же понимаешь что выпуск релизов и разработка разные вещи? кроме того для CI это можно настроить единожды.

[berezovsky.livejournal.com]

А скрипт для CI положить в репозиторий с базовыми проектами, чтобы CI определял изменения в репозитории и перенастраивал сам себя! O_O

[berezovsky.livejournal.com]

Круиз контроль вроде умел запускать билд и прочее по изменению в репозитории, только надо скрипт писать, какие билды по каким изменениям запускать и чё ещё делать.

[darkdrip.livejournal.com]

Юра, ты опять бредишь? ты щизофреник, тебя надо лечить.

[berezovsky.livejournal.com]

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

[osdm.livejournal.com]

Не понял вашей проблемы с 50-100 проектами в *.sln. У нас в *.sln около 200 проектов, меркуриал, три субрепо, CI через TeamCity. Все отлично работает и собирается через msbuild (правда, в скриптах для msbuild есть неизвестная мне магия).

[anonim-legion.livejournal.com]

Сначала прочитал как Меркуриал, субрепозитории и 1С. Аж интересно стало.

[theaspect.livejournal.com]

А в чем проблема? Пусть все собирается по мере поступления, а бинарные артефакты хранятся отдельно.

PS Специально посмотрел: nuget позволяет свои репозитории создавать

[permea-kra.livejournal.com]

Просто удивительно какие костыли городят люди, ниасилившие Make.

[metaclass.livejournal.com]

Тут msbuild, какой еще нахрен мейк?