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

Question

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

1. Строительство deb пакетов из C++ проектов (некоторые из них зависит, другие являются зависимостью);
2. Фотографии здания от Docker контейнеры;
3. Запуск некоторых процессов в конечной точке;

Как вы можете заметить, мы столкнулись с сильно разветвленной цепью рабочих мест запускаемых друг с другом. И каждое обновление любого из вышеперечисленных проектов должно проходить по всей цепочке заданий и запускать окончательную работу (process I). Таким образом, было бы неплохо использовать какой-то Jenkins плагинов, которые будут:

• управления такой сложной структурой рабочих мест (я пытался использовать Build Pipeline Plugin и у меня создалось впечатление, что этот инструмент подходит для «линейного» работы цепи);
• Обеспечьте чистый способ передачи параметров между условиями работы.

Answer 1

Ну, для передачи параметров, вы должны использовать Parameterized Trigger Plugin.

Для более асинхронного прохождения параметров, вы использование EnvInject plugin (это очень полезно и гибкие для всех видов вещей, и учитывая вашу сложность, может оказаться полезной, независимо, если вы используете его для передачи параметров или нет)

Что касается контроля, исследования в области Workflow plugin. Он позволяет записывать весь поток выполнения в собственный скрипт Groovy, с мелким гранулированным контролем. Другие ссылки:
Официальных - https://jenkins-ci.org/content/workflow-plugin-10
Учебник - https://github.com/jenkinsci/workflow-plugin/blob/c15589f/TUTORIAL.md#pausing-flyweight-vs-heavyweight-executors

Answer 2

Как @slav упоминался, Workflow плагин должен быть в состоянии справиться с таким сложным потоком управления, в том числе параллельной обработки подзадач, простой обработки переменных в течение всего процесса (были бы просто Groovy локальными переменными) и Docker support.

Вы можете, конечно, организовать весь этот процесс за один build.gradle (или Makefile, если на то пошло). Это было бы подходящим, если бы вы не пропустили все шаги на одном и том же рабстве Дженкинса и не нуждались в том, чтобы взаимодействовать с Jenkins или сообщать Jenkins каким-либо конкретным способом в середине сборки.