У плагина Jenkins Build Flow возникают проблемы с передачей параметров между сборками

У меня есть набор параметризованных сборок в Jenkins, для сборки которых мне нужно нажать «Создать сейчас», а затем ввести значение параметра (в данном случае называемое GIT_TAG_NAME). Я хотел бы запустить набор этих параметризованных сборок, которые используют один и тот же параметр, не вводя его несколько раз.

Я пытаюсь заставить это работать с плагином Build Flow (https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Plugin), создавая основной поток сборки, который запускает все остальные сборки, но я не понимаю синтаксис плагина, или, может быть, это просто невозможно.

Мой DSL выглядит так:

out.println "-------------------------" 
out.println 'Building all OTA builds at tag: '
out.println params["GIT_TAG_NAME"]
out.println "-------------------------"

build( "SomeOTA-Build-1", param1: params["GIT_TAG_NAME"] )
build( "SomeOTA-Build-2", param1: params["GIT_TAG_NAME"] )

Оператор печати печатает параметр правильно, но дочерние сборки, похоже, не получают переданный им параметр.


continuous-integration jenkins build-automation
person joseph.hainline    schedule 22.10.2012    source источник
comment
Это должно работать с плагином потока сборки - в моей настройке я могу передавать параметры, как вы описываете. Он работает с указанием параметра SomeOTA-Build-1 и без него. Параметр доступен как переменная среды сборки в SomeOTA-Build-1 с именем param1.   -  person Marijn    schedule 03.04.2013
comment
Комментарий выше содержит правильный ответ. Плагин потока сборки требует, чтобы вы назвали параметр, который вы передаете. В вашем случае это будет равно build( "someOTA-Build-1", GIT_TAG_NAME: params["GIT_TAG_NAME"] )Все слишком короткие примеры на вики-странице плагина имеют сборку с параметром с именем param1.   -  person thuovila    schedule 01.10.2013

Ответы (1)


arrow_upward
2
arrow_downward

Попробуйте использовать плагин параметризованного триггера -

  1. Установите Job-A с параметром GIT_TAG_NAME — это ваш «интерфейс».

  2. Установите Job-B1, Job-B2 и Job-B3 с одним и тем же параметром GIT_TAG_NAME — они выполняют фактическую работу.

  3. Установите для параметра Job-A значение Запускать параметризованную сборку в других проектах (в Действиях после сборки)
    и передайте Текущие параметры сборки к запущенным заданиям
    (требуется триггер для каждого производного задания — либо с одинаковыми, либо с разными условиями)


Теперь запуск Задания-A приведет к настройке других заданий с передачей им значения GIT_TAG_NAME.

РЕДАКТИРОВАТЬ:
Существует плагин от TIKAL, который использует другой подход:
< href="https://wiki.jenkins-ci.org/display/JENKINS/Multijob+Plugin" rel="nofollow">Подключаемый модуль Multijob пытается сжать все этапы работы в один большой job
(не пробовал, поэтому не могу комментировать этот подход).

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

person Gonen    schedule 23.10.2012
comment
Спасибо за ответ. Это было как раз то, что мне было нужно. Не видел его среди сотен плагинов Jenkins. :) - person joseph.hainline; 23.10.2012
comment
Что ж, большинство пользователей хотят создать одно и то же «задание», но с разными конфигурациями, поэтому они используют Задание с несколькими конфигурациями (или "Матрица") . - person Gonen; 26.10.2012