У меня есть два задания в jenkins, оба из которых нуждаются в одном и том же параметре.
Как запустить первое задание с параметром, чтобы при запуске второго задания использовался тот же параметр?
У меня есть два задания в jenkins, оба из которых нуждаются в одном и том же параметре.
Как запустить первое задание с параметром, чтобы при запуске второго задания использовался тот же параметр?
Вы можете использовать Parameterized Trigger Plugin, который позволит вам передавать параметры из одной задачи в другую.
Вам также нужно добавить этот параметр, который вы передали из апстрима в нисходящий поток.
Действия 1.Post-Build > Выберите "Trigger параметризованная сборка для других проектов"
2.Введите переменную окружения со значением. Значение также может быть параметрами сборки Jenkins.
Подробные шаги можно увидеть здесь: -
Надеюсь, что это полезно:)
Принятый ответ здесь не работает для моего варианта использования. Мне нужно было иметь возможность динамически создавать параметры в одном задании и передавать их в другое. Как отмечает Марк МакКенна, по-видимому, нет способа экспортировать переменную из этапа сборки оболочки в действия после сборки.
Я нашел обходной путь, используя Parameterized Trigger Plugin, записав значения в файл и используя этот файл в качестве параметров для импорта через "Добавить действие после сборки" → "Триггерная параметризованная сборка...", затем выбрав "Добавить параметры" - > "Параметры из файла свойств".
(для попутчиков)
Если вы строите серьезный конвейер с Build Flow Plugin, вы можете передавать параметры между заданиями с DSL следующим образом:
Предполагая доступный строковый параметр "CVS_TAG", чтобы передать его другим заданиям:
build("pipeline_begin", CVS_TAG: params['CVS_TAG'])
parallel (
// will be scheduled in parallel.
{ build("pipeline_static_analysis", CVS_TAG: params['CVS_TAG']) },
{ build("pipeline_nonreg", CVS_TAG: params['CVS_TAG']) }
)
// will be triggered after previous jobs complete
build("pipeline_end", CVS_TAG: params['CVS_TAG'])
Совет для отображения доступных переменных/параметров:
// output values
out.println '------------------------------------'
out.println 'Triggered Parameters Map:'
out.println params
out.println '------------------------------------'
out.println 'Build Object Properties:'
build.properties.each { out.println "$it.key -> $it.value" }
out.println '------------------------------------'
Я думаю, что ответ выше нуждается в некотором обновлении:
Я пытался создать динамический каталог для хранения своих артефактов сборки из исходной версии, поэтому я хотел передать номер сборки из своей исходной работы в последующую, я попробовал описанные выше шаги, но не смог заставить его работать. Вот как это работает:
Это связано с тем, что в новой версии jenkins вы также должны определить переменную в последующем задании. Я надеюсь, что это полезно.
Просто добавьте свой ответ в дополнение к Найджелу Кирби, поскольку я еще не могу прокомментировать:
Чтобы передать динамически созданный параметр, вы также можете экспортировать переменную в разделе "Выполнить оболочку", а затем передать ее через "Триггер-параметризованная сборка для других проектов" = > "Предопределенные параметры" = > дать "YOUR_VAR = $YOUR_VAR '. Моя команда использует эту функцию для передачи версии пакета npm из задания сборки в задания развертывания.
UPDATE: выше работает только для введенных параметров Дженкинса, параметр, созданный из оболочки, все равно должен использовать тот же метод. например. echo YOUR_VAR = ${YOUR_VAR} > variable.properties и передать этот файл ниже по течению
Вы можете использовать Hudson Groovy builder, чтобы сделать это.
Первое задание в конвейере
Второе задание в конвейере
Читая ответы, я не вижу другого варианта, который мне нравится, поэтому предложу его тоже. Мне нравится параметризация рабочих мест, но она не всегда хорошо масштабируется. Если у вас есть задания, которые не находятся непосредственно перед первой задачей, а находятся ниже по конвейеру, вам не нужно параметризировать каждую работу в конвейере, чтобы иметь возможность передавать параметры на всем протяжении. Или, если у вас есть большое количество параметров, используемых различными другими заданиями (особенно те, которые не обязательно привязаны к одному родительскому или основному заданию), снова параметризация не работает.
В этих случаях я предпочитаю выводить значения в файл свойств, а затем вставлять их в любую нужную мне работу с помощью плагина EnvInject. Это можно сделать динамически, что является еще одним способом решения проблемы из другого ответа выше, где параметризованные задания все еще использовались. Это решение очень хорошо масштабируется во многих сценариях.
Я столкнулся с той же проблемой, когда мне пришлось передать версию pom для последующей работы Rundeck.
То, что я делал, использовало ввод параметров через файл свойств как таковой:
1) Создание свойств в файле свойств через оболочку:
Действия сборки:
Например: определение свойств
2) Передача определенных свойств следующему заданию: Действия после сборки:
Например: передача свойств
3) Тогда было возможно использовать $POM_VERSION как таковую в работе Rundeck в нисходящем направлении.
/!\Jenkins Версия: 1.636
/!\По какой-то причине при создании инициированной сборки необходимо было добавить параметр "Текущие параметры сборки" для передачи свойств.
См. мой ответ в этом другом сообщении:
Работал для меня (параметр должен быть указан в обоих заданиях, а не только для родительского задания)