5

В настоящее время мы используем Jenkins CI 1.643 (я полагаю) с плагином Multijob и Job DSL.
Собрание заданий создается с использованием Job DSL, а также multijob, который содержит все другие задания в определенном порядке (сборка, анализ, модульный тест, интеграционный тест и т. Д.).Миграция из Jenkins Multijob to Pipeline plug-in

Я заинтересован в модернизации до Jenkins 2 и использовании плагина Pipeline (ранее известного как плагин Workflow). Плагин Pipeline предлагает приятное графическое представление, а также предлагает некоторые дополнительные функции, которых у нас нет в настоящее время (например, действие «пауза», требующее взаимодействия с человеком). Проект Blue Ocean также кажется очень гладким, но требует подключаемого модуля Pipeline.

Что касается миграции, у меня есть несколько вопросов:

  • Должен ли я продолжать использовать работы DSL? У нас есть действительно хороший шаблонный механизм, созданный в Groovy, поэтому нам нужно только ввести несколько деталей о продукте (например, используемый компилятор и определенные пороговые значения качества). Думаю, я хотел бы сохранить это.
  • Есть ли руководство по «переносу» из подключаемого модуля Multijob к подключаемому модулю Pipeline?
  • Какие вещи я должен иметь в виду? (основные различия между плагинами.)
+0

Просто начните писать сценарий конвейера и спросите StackOverflow, где у вас есть конкретные проблемы. – StephenKing

+1

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

+0

Я не знаю руководства (но поиск таких вещей - это «против правил stackoverflow»). Мне удалось заменить все JobDSL на DSL-конвейер. Но, безусловно, поддержка в разных плагинах далеко не такая хорошая (но, безусловно, улучшится). Что касается multijob, посмотрите [этот ответ] (http://stackoverflow.com/questions/37661602/how-to-set-up-a-github-pull-request-build-in-a-jenkinsfile/37661924# 37661924). – StephenKing

ответ

1

Не полный ответ, но:

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

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

Должен ли я продолжать использовать Job DSL?

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