Дженкінс - передача змінних між робочими місцями?

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

Як я можу запустити перше завдання з параметром, щоб, коли воно запускає друге завдання, використовувався той самий параметр?

Ви можете використовувати параметризований плагін запуску, який дозволить вам передавати параметри від одного завдання до іншого.

Вам також потрібно додати цей параметр, який ви передали з вищого та нижчого потоку.

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

2. Введіть змінну середовища зі значенням. Значенням також можуть бути Параметри побудови Дженкінса.

Детальні кроки можна переглянути тут: -

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 вимагає від вас також визначити змінну в подальшому завданні. Сподіваюся, це корисно.

(для колег Google)

Якщо ви будуєте серйозний конвеєр за допомогою плагіна 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 із завдання збірки на завдання розгортання

ОНОВЛЕННЯ: вище працює лише для введених параметрів Дженкінса, параметр, створений із оболонки, все одно повинен використовувати той самий метод. напр. echo YOUR_VAR = $ {YOUR_VAR}> variable.properties і передайте цей файл нижче

Я зіткнувся з такою ж проблемою, коли мені довелося передати пом-версію на нижчу роботу Rundeck.

Що я зробив, використовував введення параметрів через файл властивостей як такий:

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

Дії побудови:

• Виконайте сценарій оболонки
• Введіть змінні середовища

Наприклад: визначення властивостей

2) Передача визначених властивостей до подальшого завдання: Дії збірки після:

• Запустити параметризовану побудову на іншому проекті
• Додати параметри: поточні параметри збірки
• Додати параметри: заздалегідь визначені параметри

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

3) Тоді можна було використовувати $ POM_VERSION як таку в подальшій роботі Rundeck.

/! \ Версія Дженкінса: 1.636

/! \ З якоїсь причини під час створення запущеної збірки для передачі властивостей було потрібно додати опцію 'Поточні параметри збірки'.

Читаючи відповіді, я не бачу іншого варіанту, який мені подобається, тому я його також запропоную. Я люблю параметризацію робочих місць, але це не завжди добре масштабується. Якщо у вас є завдання, які знаходяться не безпосередньо за першим завданням, а далі по конвеєру, ви насправді не хочете параметризувати кожне завдання в конвеєрі, щоб мати можливість передавати параметри до кінця. Або якщо у вас є велика кількість параметрів, що використовуються для різних інших завдань (особливо тих, які не обов’язково прив’язані до одного батьківського чи головного завдання), знову параметризація не працює.

У цих випадках я віддаю перевагу виведенню значень у файл властивостей, а потім ввожу це в будь-яку роботу, яка мені потрібна, за допомогою плагіна EnvInject . Це можна зробити динамічно, що є ще одним способом вирішення проблеми з іншої відповіді вище, де все ще використовувались параметризовані завдання. Це рішення дуже добре масштабується у багатьох сценаріях.

Для цього ви можете використовувати конструктор Hudson Groovy .

Перша робота в трубопроводі

Друга робота в трубопроводі