Подтвердить что ты не робот

Дженкинс - передача переменных между заданиями?

У меня есть два задания в jenkins, оба из которых нуждаются в одном и том же параметре.

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

4b9b3361

Ответ 1

Вы можете использовать Parameterized Trigger Plugin, который позволит вам передавать параметры из одной задачи в другую.

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

Ответ 2

Действия 1.Post-Build > Выберите "Trigger параметризованная сборка для других проектов"

2.Введите переменную окружения со значением. Значение также может быть параметрами сборки Jenkins.

Подробные шаги можно увидеть здесь: -

https://itisatechiesworld.wordpress.com/jenkins-related-articles/jenkins-configuration/jenkins-passing-a-parameter-from-one-job-to-another/

Надеюсь, что это полезно:)

Ответ 3

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

Я нашел обходной путь, используя Parameterized Trigger Plugin, записав значения в файл и используя этот файл в качестве параметров для импорта через "Добавить действие после сборки" → "Триггерная параметризованная сборка...", затем выбрав "Добавить параметры" - > "Параметры из файла свойств".

Ответ 4

(для попутчиков)

Если вы строите серьезный конвейер с 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 '------------------------------------'

Ответ 5

Я думаю, что ответ выше нуждается в некотором обновлении:

Я пытался создать динамический каталог для хранения своих артефактов сборки из исходной версии, поэтому я хотел передать номер сборки из своей исходной работы в последующую, я попробовал описанные выше шаги, но не смог заставить его работать. Вот как это работает:

  1. Я скопировал артефакты из моей текущей работы, используя плагин копирования артефактов.
  2. В последующем действии сборки верхнего уровня я добавил переменную типа "SOURCE_BUILD_NUMBER = $ {BUILD_NUMBER}" и настроил ее для запуска нижестоящего задания.
  3. Все работало, за исключением того, что моя нижестоящая работа не смогла получить $ SOURCE_BUILD_NUMBER для создания каталога.
  4. Итак, я обнаружил, что для использования этой переменной я должен определить ту же переменную в задании вниз по потоку, что и переменная параметра, как на этом рисунке ниже:

enter image description here

Это связано с тем, что в новой версии jenkins вы также должны определить переменную в последующем задании. Я надеюсь, что это полезно.

Ответ 6

Просто добавьте свой ответ в дополнение к Найджелу Кирби, поскольку я еще не могу прокомментировать:

Чтобы передать динамически созданный параметр, вы также можете экспортировать переменную в разделе "Выполнить оболочку", а затем передать ее через "Триггер-параметризованная сборка для других проектов" = > "Предопределенные параметры" = > дать "YOUR_VAR = $YOUR_VAR '. Моя команда использует эту функцию для передачи версии пакета npm из задания сборки в задания развертывания.

UPDATE: выше работает только для введенных параметров Дженкинса, параметр, созданный из оболочки, все равно должен использовать тот же метод. например. echo YOUR_VAR = ${YOUR_VAR} > variable.properties и передать этот файл ниже по течению

Ответ 7

Вы можете использовать Hudson Groovy builder, чтобы сделать это.

Первое задание в конвейере

enter image description here

Второе задание в конвейере

enter image description here

Ответ 8

Читая ответы, я не вижу другого варианта, который мне нравится, поэтому предложу его тоже. Мне нравится параметризация рабочих мест, но она не всегда хорошо масштабируется. Если у вас есть задания, которые не находятся непосредственно перед первой задачей, а находятся ниже по конвейеру, вам не нужно параметризировать каждую работу в конвейере, чтобы иметь возможность передавать параметры на всем протяжении. Или, если у вас есть большое количество параметров, используемых различными другими заданиями (особенно те, которые не обязательно привязаны к одному родительскому или основному заданию), снова параметризация не работает.

В этих случаях я предпочитаю выводить значения в файл свойств, а затем вставлять их в любую нужную мне работу с помощью плагина EnvInject. Это можно сделать динамически, что является еще одним способом решения проблемы из другого ответа выше, где параметризованные задания все еще использовались. Это решение очень хорошо масштабируется во многих сценариях.

Ответ 9

Я столкнулся с той же проблемой, когда мне пришлось передать версию pom для последующей работы Rundeck.

То, что я делал, использовало ввод параметров через файл свойств как таковой:

1) Создание свойств в файле свойств через оболочку:

Действия сборки:

  • Выполнить оболочку script
  • Инъекционные переменные среды

Например: определение свойств

2) Передача определенных свойств следующему заданию: Действия после сборки:

  • Триггер с параметризацией построена на другом проекте
  • Добавить параметры: Текущие параметры сборки
  • Добавить параметры: предопределенные параметры

Например: передача свойств

3) Тогда было возможно использовать $POM_VERSION как таковую в работе Rundeck в нисходящем направлении.

/!\Jenkins Версия: 1.636

/!\По какой-то причине при создании инициированной сборки необходимо было добавить параметр "Текущие параметры сборки" для передачи свойств.

Ответ 10

См. мой ответ в этом другом сообщении:

Работал для меня (параметр должен быть указан в обоих заданиях, а не только для родительского задания)

fooobar.com/info/92791/...