Может ли мастер Дженкинс запускать задания на удаленных Дженкинсах?

Мы переходим с CruiseControl.NET на Jenkins просто для синхронизации с партнером, чтобы у нас не было двух разных сценариев CI. Мы пытаемся настроить Jenkins для выполнения чего-то похожего на то, что у нас было в CruiseControl, когда централизованный сервер запускал проекты (задания в jenkins) на удаленных машинах сборки.

У нас есть несколько машин для сборки, связанных с одним проектом, поэтому, когда мы создаем проект с централизованного сервера CI, он будет вызывать проекты на удаленных серверах CI. Удаленные серверы CI получат версию из проекта централизованного сервера CI.

В CruiseCruise control мы настраиваем проект, который будет выполнять forceBuild удаленные проекты. Проекты на машинах сборки использовали remoteProjectLabeller для получения номера версии, чтобы они всегда были синхронизированы.

Чтобы получить главный номер сборки:

<labeller type="remoteProjectLabeller">
  <project>MainProject</project>
  <serverUri>tcp://central-server:21234/CruiseManager.rem</serverUri>
</labeller>

Чтобы вызвать удаленные проекты:

<forcebuild>
    <project>RemoteBuildMachineA</project>
    <serverUri>tcp://remote-server:21234/CruiseManager.rem</serverUri>
    <integrationStatus>Success</integrationStatus>
</forcebuild>

Пока что в jenkins я установил вторичный сервер в качестве подчиненного, используя запуск веб-сайта java, но я не знаю, как бы я мог заставить главного jenkins вызывать настройку проектов на подчиненных устройствах.

Могу ли я настроить Jenkins для вызова проектов (заданий) на подчиненных устройствах?

Могу ли я заставить ведомые устройства вытаскивать номер версии из ведущего устройства?

ИЗМЕНИТЬ -

Позвольте мне добавить дополнительную информацию.

  • Ведущее устройство и ведомые устройства удаленной сборки работают под управлением Windows.
  • У нас был центральный мастер CruiseControl, который запускал удаленные проекты в одно и то же время, поэтому они выполнялись одновременно и хотели бы, чтобы то же самое было с jenkins, если это возможно.

person Andy Arismendi    schedule 01.05.2012    source источник


Ответы (4)


У Дженкинса есть концепция агентов сборки, которые, возможно, лучше подходят для вашего сценария - есть мастер, который запускает сборку и ведомые устройства, которые ее выполняют. Затем сборка может быть ограничена только некоторыми категориями ведомых устройств (например, если она зависит от определенного программного обеспечения, а не для всех агентов). Все данные управляются централизованно мастером, и я считаю, что это именно то, чего вы пытаетесь достичь.

person skolima    schedule 01.05.2012
comment
+1 да, я думал о конфигурации с точки зрения круиз-контроля. Спасибо. - person Andy Arismendi; 17.05.2012

В Jenkins невозможно запустить сборку на ведомом устройстве, то есть там, где запускается сборка, не контролируется тем, кто ее запускает. Это контролируется настройками самого задания. Каждое задание имеет параметр «Ограничить, где это задание может выполняться».

В вашем случае у вас, вероятно, будет два задания: A и B. A будет ограничено запуском на «master», а B будет настроен для работы на «slavename». Тогда все, что остается сделать, это чтобы A активировал B.

Но у вас были и другие ограничения: вы хотите, чтобы A и B извлекали одну и ту же версию из системы управления версиями, и вы хотите, чтобы A и B работали параллельно. Есть много способов сделать это, но, вероятно, самый простой - определить задание с несколькими конфигурациями.

Невозможно превратить существующее задание свободного стиля в задание с несколькими конфигурациями, поэтому вам придется создать новое задание.

  • Выбрать новую работу
  • Выберите Создать новый проект с несколькими конфигурациями. Добавьте имя.
  • В разделе «Матрица конфигурации» откройте раскрывающийся список «Добавить ось».
  • Выберите рабов
  • Проверьте ведущего и ведомого
  • Добавьте информацию SCM и этап (ы) сборки

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

person sti    schedule 01.05.2012
comment
В Jenkins невозможно запустить сборку на ведомом устройстве, т.е. там, где запуск сборки не контролируется тем, кто ее запускает - это не на 100% правильно. Вы можете указать метку узла в качестве параметра с помощью подключаемого модуля параметра метки узла, а затем используйте значение этого параметра в поле Ограничить, где может выполняться это задание. - person malenkiy_scot; 02.05.2012
comment
Я настраиваю тестовую среду с тремя виртуальными машинами: a, b и c. A - главный, b и c - подчиненные. Я создал задание с несколькими конфигурациями и в матрице конфигурации выбираю только узел b, потому что хочу, чтобы он выполнялся только на этой виртуальной машине. Однако, когда я запускаю сборку, она запускается от мастера. Почему это? Я ожидаю, что он запустит его на выбранном мной узле. - person Andy Arismendi; 02.05.2012
comment
@ Энди Арисменди, ты уверен? Идем к заданию, выбираем последнюю сборку. Он покажет маленькие шарики, соответствующие вашим дочерним сборкам (может быть, только один, если у вас только одна дочерняя сборка, тогда рядом с ним будет написано «по умолчанию»). Шарики будут синими, красными или серыми - в зависимости от статуса. Нажмите на один из не-серых шаров. Это статус вашего ребенка. Предполагается, что ребенок будет работать на ведомом b. С другой стороны, задание верхнего уровня может выполняться где угодно (если только оно не привязано к узлу с помощью модуля Matrix Tie Parent). - person malenkiy_scot; 02.05.2012
comment
Энди, ты, наверное, запутался в родительской сборке. Когда выполняется задание с несколькими конфигурациями, сначала создается родительская сборка, а затем одна сборка для каждой подконфигурации. Родительская сборка остается активной, пока не будут завершены все сборки подконфигурации. Родительская сборка проверяет только исходный код, но не выполняет никаких шагов сборки, поэтому вы можете игнорировать это. Родительская сборка выполняется на случайном узле, но есть плагин, который позволяет привязать его к узлу, как описано выше malenkiy_scot. Обычно вам не нужно об этом заботиться. - person sti; 02.05.2012
comment
Спасибо, ребята, цените помощь. В итоге я выбрал другой подход, поэтому я поставил это ответ на вопрос. - person Andy Arismendi; 08.05.2012

По URL-адресу / jenkins / computer вы можете добавлять, удалять и перенастраивать «узлы», которые являются локальными или удаленными «агентами сборки».

Затем можно ограничить выполнение заданий на определенных агентах сборки или следовать различным правилам для выбора подходящего агента сборки из доступных агентов.

person Edwin Buck    schedule 01.05.2012
comment
Извините, но похоже, что вы не говорите здесь ничего нового из того, что уже было предоставлено в предыдущих ответах. - person malenkiy_scot; 02.05.2012

Я слишком много думал о Jenkins, как о CruiseControl, где задание определяется на удаленной машине. Таким образом, в Jenkins удаленные проекты определены на главном сервере и делегированы удаленному компьютеру через агента.

Я использовал агент Java Web Start, установленный как служба Windows на удаленных машинах. Чтобы определенные задания выполнялись на определенных удаленных машинах, я определил каждый удаленный узел с уникальной меткой в ​​его подчиненной конфигурации. Чтобы привязать определенные задания к определенным ведомым устройствам, я использовал метку ведомого устройства в каждой конфигурации задания («Ограничить, где этот проект может быть запущен»).

Чтобы запускать задания с помощью одного основного задания, я создал задание в свободном стиле, для которого задано только «Создание других проектов», и предоставил список или имена проектов, разделенных запятыми. Эта работа параллельно создает последующие задания.

Я все еще ищу способ отправить главный номер сборки последующим заданиям, чтобы они всегда синхронизировались. (Это используется для версий DLL и т. Д.)

person Andy Arismendi    schedule 06.05.2012