Настройка нескольких репозиториев Mercurial в Jenkins
Мы используем около 30 репозиториев для обработки всего нашего программного обеспечения в нашей компании. Наш код смешан между C #, C ++ и python. Изначально мы собирались использовать TeamCity для нашего CI-сервера, и я обнаружил, что это чрезвычайно легко настроить с учетом того, как устроена наша система репо. Однако мой менеджер решил, что вместо этого мы должны использовать Jenkins.
Когда я начал настраивать Jenkins, я обнаружил, что он, естественно, не поддерживает несколько репозиториев для одного задания. Для этого есть плагин, но на вики-странице разработчик плагина признал, что это скорее доказательство концепции, чем надежная функция, поэтому я не решаюсь использовать ее, хотя в конце концов, я могу быть вынужден.
Следует ли настраивать задания независимо от каждого репо, где можно запускать модульные тесты и сборки? Я не считаю это жизнеспособным вариантом, поскольку наши репозитории зависят друг от друга, если только мне не хватает конфигурации или другого плагина. Или могут ли сборки зависеть друг от друга, чтобы что-то подобное стало возможным?
Наша конечная цель состоит в том, чтобы Jenkins также управлял нашими развертываниями в нашей промежуточной области разработки. Это оказалось легко сделать в TeamCity, и я думаю, что это должно быть так же легко сделать и в Jenkins. Может ли работа получить доступ к репозиториям других вакансий? Я не уверен, что это ясно, но в городе команды были переменные проекта, которые могли позволить вам выбрать любое определенное вами репо (например, % FIRST_REPO% , % SECOND_REPO% ])
Подводя итог, можно сказать, есть ли в Jenkins надежный и чистый способ работы с несколькими ртутными репозиториями? Могут ли другие задания зависеть от другого и получить доступ к чужому репозиторию?
Я надеюсь, что кто-то с большим опытом CI, чем у меня, сможет помочь. Возможно, для нашей установки лучше подойдет другой CI-сервер, есть ли у кого-нибудь опыт работы с BuildBot?
Я подумал, что было бы полезно перечислить, как устроены репозитории:
- app1.application
- app1.common
- app1.deploy
- app2.application
- app2.common
- app2.deploy
- platform.common
- platform.deploy
Где app1 и app2 будет зависеть от некоторых ресурсов из platform.common .