Може ли майстор Дженкинс да изпълнява задачи на отдалечени Дженкинс?

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

Имаме множество машини за изграждане, свързани с един проект, така че когато изградим проекта от централизирания CI сървър, той ще извика проектите на отдалечените CI сървъри. Отдалечените CI сървъри биха изтеглили версията от централизирания CI сървърен проект.

В контрола на CruiseCruise настройваме проект, който ще направи 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 web start, но не знам как бих накарал главния 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 не е възможно да се задейства компилация на slave, т.е. когато компилацията се изпълнява, не се контролира от този, който я задейства. Контролира се от настройките на самото задание. Всяко задание има настройка, наречена „Ограничаване къде може да се изпълнява това задание“.

Във вашия случай вероятно ще имате две задачи: 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
@AndyArismendi, сигурен ли си? Отидете на заданието, изберете последната компилация. Ще покаже малки топки, съответстващи на изграждането на вашето дете (може би само едно, ако имате само едно изграждане на дете, тогава до него ще пише „по подразбиране“). Топките ще бъдат сини, червени или сиви - в зависимост от състоянието. Кликнете върху една от несивите топки. Това е състоянието на вашето дете. Детето трябва да работи на подчинен b. Задача от най-високо ниво, от друга страна, може да се изпълнява навсякъде (освен ако не е свързана с възел с Matrix Tie Parent plgin). - 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