(Я видел здесь и в других источниках некоторые предложения, связанные с подключаемым модулем NodeLabel для решения подобных проблем, но еще не нашел надежного примера того, как на самом деле ИСПОЛЬЗОВАТЬ NodeLabel для этой цели.)) эм>
Прямо сейчас триггер gerrit запускает сборку на основе заданной ветки в репозитории git одного из моих проектов.
Это создает ОДНО родительское задание P, которое использует подключаемый модуль Parameterized Trigger для создания еще двух сборок проекта (обозначенных двумя метками) на двух подчиненных устройствах с двумя разными ОС (X1 и Y1).
Завтра у меня будет новая версия Y1 для сборки под названием Y2, а X1 устарела. Я могу определить допустимые цели для этой версии моего кода в репозитории git кода.
В этот момент у меня есть родитель (P) и три типа узлов (X1, Y1 Y2), с которыми нужно иметь дело. Из-за ветвления я также должен поддерживать возможность создания как устаревшего кода (для X1 и Y1), так и нового кода (только для Y2).
Я мог бы создать еще одно задание Y2 (которое идентично Y1, за исключением типа узла, который ограничивает сборку использованием статической метки), а затем во время выполнения каждого дочернего задания я мог решить, прерывать ли задание раньше (устаревшая цель ) или выполнить эту сборку. Однако при каждой сборке я теперь получаю четыре клона git, добавляющих избыточную нагрузку и трафик на сервер git: один для родительского и один для каждой цели, включая два, которые я мог определить как устаревшие во время первого шага «Выполнить оболочку». !
Это может показаться не таким уж большим, но когда мы доберемся до OS Y9, у нас может быть до десяти заданий, выполняемых для данной ветки, восемь из которых не нужны... это недопустимо. Хотя в конечном итоге более старые цели ОС будут удалены, в любой момент времени должно быть доступно несколько версий, даже если для данной сборки требуется только одна.
Сегодня первый шаг сборки моей сборки на Jenkins для любой цели использует «Выполнить оболочку» для сбора полезной информации для передачи дочерним заданиям.
Однако дочерние задания жестко запрограммированы в поле «Запуск/вызов сборок в других проектах -> Проекты для сборки» (вместе с другими важными настройками, такими как способ и время их блокировки!) Если бы вместо этого я мог поместить переменную там (или как-то сослаться на переменную, которую я установил программно), я мог бы просто установить эту переменную на шаге оболочки перед ней, и тогда она будет заполнена именно теми подпроектами, которые ей требуются! Подпроекты «знают», на каких узлах/группах узлов им разрешено выполняться.
Короче говоря, мой проект выполняет сценарий, этот сценарий устанавливает переменную, эта переменная определяет вызываемые подпроекты, как если бы я редактировал конфигурацию для этой сборки (например, MY_PROJ_TO_BUILD="X1 Y1" заполняет "Проекты для сборки " поле). Следующий шаг продолжается созданием этих подпроектов обычным способом. Это все, что мне нужно, и, конечно же, без потери текущей функциональности и без прямого взлома Дженкинса. (Поскольку они срабатывают от gerrit, запуск нескольких версий gerrit и/или Jenkins также не является приемлемым вариантом.)
NodeLabel уже упоминался, но я еще не видел примера его эффективного использования для такого рода проблем (примеры, которые я видел, крайне расплывчаты). Итак, если у вас есть пример, который отвечает всем требованиям, или указатель на него, я был бы рад его увидеть. Точно так же, если у вас есть другая идея/решение, я буду рад ее услышать. Я могу представить некоторые причины, по которым то, что я хотел, сработало (переменная подпрограмма в поле «проекты для создания») не работает и, возможно, не может, но, безусловно, создание множества ненужных клонов только для того, чтобы определить небольшое подмножество целей, необходимых для сборки данной ветки, также не является оптимальным.
(Примечание: это для одного проекта/репозитория... на самом деле я имею дело с десятками, и я должен сказать, что создаю несколько идентичных, но для типа узла, на котором они работают, подпроектов для каждого один сам по себе является фарсом... но это единственный способ, который я нашел до сих пор, который обеспечивает обратную совместимость сборки, когда может потребоваться построить несколько целей для данной сборки ветки.)
