Плагин Job DSL против плагина конвейера

У меня большой опыт работы с обоими. Краткий ответ заключается в том, что Job DSL существует гораздо дольше и был решением Netflix с открытым исходным кодом для «кодирования» Дженкинса. Это позволило вам ввести логику и переменные в сценарии ваших заданий Jenkins, и обычно эти задания можно использовать для формирования своего рода «конвейера» для конкретного проекта. Этот плагин получил довольно много внимания как обычный способ включения шаблонов заданий и написания сценариев.

Jenkins Pipeline (2.0) - это новое воплощение задания Jenkins, которое полностью основано на DSL и пытается устранить необходимость сшивать несколько заданий для заполнения одного конвейера, который на сегодняшний день был наиболее распространенным использованием Job DSL. Первоначально, поскольку конвейерный DSL не предлагал многих функций, которые предоставлял Job DSL, и, как упоминалось выше, Job DSL позволял вам создавать конвейерные задания, их можно было использовать вместе для определения конвейера.

Сегодня у IMO мало причин для использования Job DSL, потому что Pipeline - это поддерживаемый Jenkins механизм для написания сценариев конвейеров Jenkins, и он соответствует или превосходит многие функции Job DSL. Новые плагины разрабатываются изначально для Pipeline, а те, которые этого не делают, разработчики Jenkins поощряют к интеграции с Pipeline. И у Pipeline есть несколько преимуществ:

• Нет необходимости «засеивать» задания с помощью конвейера, как в случае с Job DSL, поскольку конвейер является самим заданием. С Job DSL это просто сценарий, который создает другие задания.
• С конвейером у вас есть такие функции, как параметризованный шаг ручного ввода, позволяющий указать логику промежуточного потока внутри конвейера.
• Логика, которую можно включить в Job DSL, ограничивается созданием самих заданий; тогда как с конвейером вы можете включить логику непосредственно в задание.
• Job DSL просто намного сложнее создать базовый конвейер доставки, используя, например, подключаемый модуль Build Pipeline; при использовании конвейера ваш файл будет меньше, а синтаксис короче. И если вы используете Job DSL для создания заданий конвейера, я больше не вижу в этом особой ценности, учитывая готовые функции шаблонов, доступные в Jenkins Pipeline.

Наконец, Jenkins Pipeline - безусловно, самая распространенная функция Jenkins прямо сейчас. Ознакомьтесь с повесткой дня Jenkins World 2016, и вы увидите прибл. 50% сессий связаны с конвейером. Нет для Job DSL.

Я считаю, что идеальным подходом является использование обоих. Pipeline - это новая встроенная функция Jenkins, позволяющая выполнять задания в виде кода. Однако при создании Jenkins с нуля эти рабочие места все равно необходимо создать. Это означает, что Jenkins не может быть полностью написан по сценарию и построен из кода.

Что вы можете сделать, так это использовать JOB DSL для построения каркасной структуры всех заданий, а затем использовать конвейер для реализации заданий. Это позволит вам на 100% использовать скрипт Jenkins за вычетом создаваемого начального задания.

Возможно, со временем мы сможем использовать конвейер для полного управления Jenkins (безопасность, конфигурация и даже плагины). Но до тех пор я думаю, что это хороший подход - использовать DSL и конвейер.

Мой предварительный ответ, основанный на очень ограниченном опыте:

• Каждый использует свой Groovy DSL.
• Job DSL позволяет создавать другие задания в соответствии со сценарием Groovy. Итак, если вам нужен набор заданий, связанных с X (например, конвейер), вы создадите одно задание DSL задания, напишите сценарий, запустите это задание, и тогда у вас будут эти задания X плюс одно для создания этих заданий. . В этот момент было запущено только задание, которое вы создали напрямую, а созданные этим заданием - нет. OOTB, эти задания не скрыты, как модули Maven в многомодульном задании Maven, но я понимаю, что есть, по крайней мере, способ создать представление и прикрепить туда задания.
• Pipeline DSL просто зависает на неопределенное время в двух очень разных средах, в которых я его пробовал. : '(Насколько я понимаю, это известная ошибка showstopper - ищите, и вы найдете здесь несколько открытых сообщений об ошибках. В любом случае, выполнение создаваемого вами задания Pipeline фактически запускает конвейер, а не создает кучу заданий, таких как Job DSL Таким образом, триггеры для запуска задания конвейера - это триггеры для запуска конвейера, а не просто обновления заданий, которые он определяет.
• Судя по количеству загрузок, конвейер используется более широко. Конечно, Pipeline является функцией Jenkins 2.0 по умолчанию, что может объяснить недавний всплеск загрузок. Сопровождающие Jenkins обязательно хотят, чтобы вы использовали его.

Итак, резюмируем: DSL Job DSL предназначен для создания заданий, которые образуют конвейер, DSL плагина Pipeline определяет сам конвейер.

И чтобы ответить на ваш вопрос (ы): Pipeline должен получить более широкую поддержку в будущем, выглядит более простым для меня (работа - это работа, а не метазадание) и, похоже, имеет больше функций (включая рабочий процесс). Я бы использовал его, если вы не столкнетесь с вышеупомянутой ошибкой showstopper о гибели и не сможете найти исправление / обходной путь.

Есть одно важное отличие, о котором здесь пока не упоминалось: тестирование. С помощью job-dsl есть средства тестирования кода DSL перед его фиксацией в SCM: https://github.com/sheehan/job-dsl-gradle-example - это позволяет запускать локальный набор тестов в коде DSL, а также в Jenkins перед запуском кода. Насколько мне известно, в подходе "native Pipeline" нет эквивалента.