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

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

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

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

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

1. Действия после сборки> Выберите «Запускать параметризованную сборку в других проектах».

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

Подробные инструкции можно увидеть здесь: -

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

Надеюсь, это поможет :)

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

Я нашел обходной путь, используя плагин параметризованного триггера , записав значения в файл и используя этот файл в качестве параметров для импорта с помощью «Добавить действие после сборки» -> «Триггер параметризованной сборки ...», затем выбрав «Добавить параметры» - > «Параметры из файла свойств».

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

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

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

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

(для коллег-гуглеров)

Если вы создаете серьезный конвейер с помощью подключаемого модуля Build Flow , вы можете передавать параметры между заданиями с помощью 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 '------------------------------------'

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

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

ОБНОВЛЕНИЕ: выше работает только для введенных параметров Jenkins, параметр, созданный из оболочки, по-прежнему должен использовать тот же метод. например. echo YOUR_VAR = $ {YOUR_VAR}> variable.properties и передать этот файл ниже по потоку

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

Я использовал инъекцию параметров через файл свойств как таковой:

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

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

• Выполнить сценарий оболочки
• Ввести переменные среды

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

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

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

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

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

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

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

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

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

Вы можете использовать Hudson Groovy builder .

Первая работа в разработке

Вторая работа в разработке

Я понял!

Я понял это после почти 2 часов проб и ошибок.

Это РАБОТАЕТ, и это то, что вы делаете для передачи переменных удаленному заданию:

    def handle = triggerRemoteJob(remoteJenkinsName: 'remoteJenkins', job: 'RemoteJob' paramters: "param1=${env.PARAM1}\nparam2=${env.param2}")

Используйте \ n для разделения двух параметров, без пробелов ..

В отличие от параметров: '' 'someparams' ''

мы используем параметры: "someparams"

"..." - это то, что дает нам значения желаемых переменных. (Это двойные кавычки, а не две одинарные)

'' '...' '' или '...' не дадут нам этих значений. (Три одинарные кавычки или просто одинарные кавычки)

Все параметры здесь определены в блоке environment {} в начале конвейера и при необходимости изменяются поэтапно> шаги> сценарии.

Я также проверил и обнаружил, что когда вы используете "...", вы не можете использовать что-то вроде '' '... "..."' '' или "... '..'..." или любую комбинацию Это...

Уловка здесь в том, что когда вы используете "..." в разделе параметров, вы не можете передавать строковый параметр; например, это НЕ РАБОТАЕТ:

    def handle = triggerRemoteJob(remoteJenkinsName: 'remoteJenkins', job: 'RemoteJob' paramters: "param1=${env.PARAM1}\nparam2='param2'")

если вы хотите передать что-то вроде приведенного выше, вам нужно будет установить переменную окружения param2 = 'param2', а затем использовать $ {env.param2} в разделе параметров шага плагина удаленного триггера