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

Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

() translation by (you can also view the original English article)

В этой второй и заключительной части этой серии мы рассмотрим плагин Jenkins Workflow в качестве решения для создания более сложных конвейеров Jenkins.

Мы продолжим там, где часть первой из серии прекратилась. В первой части Джефф Рейфман провел вас через создание экземпляра Jenkins в Digital Ocean и создание вашей первой сборки Jenkins. Если вы еще этого не читали, я предлагаю сделать это, прежде чем продолжить. Все в порядке - я буду ждать. Я могу быть очень терпеливым ...

... Все догнали? Отличное! Давайте сделаем это.

Что такое рабочий процесс Дженкинса?

Jenkins Workflow - это плагин для Jenkins. После установки появляется новый тип элемента: «Workflow». Проекты Workflow могут использоваться для тех же целей, что и обычные проекты «Freestyle» Jenkins, но они также могут организовать гораздо более крупные задачи, которые могут охватывать несколько проектов, и даже создавать и управлять несколькими рабочими пространствами в одном рабочем процессе. Более того, все это управление может быть организовано в один скрипт, а не распространено через коллекцию конфигураций, проектов и шагов.

Предварительный процесс

Прежде чем мы начнем создавать Workflow, нам нужно установить плагин Jenkins Workflow. На панели инструментов Jenkins выберите «Управление Jenkins», затем «Управление плагинами». Перейдите на вкладку «Доступные» и найдите «Рабочий процесс».

Установите флажок для плагина Workflow, затем Установить без перезагрузки.

Теперь, готово. Существует несколько плагинов с именем «Workflow Plugin», поэтому вам нужно будет повторить вышеуказанные шаги несколько раз. Кроме того, вы также можете щелкнуть несколько флажков или установить плагин агрегатора рабочего процесса.

После того, как в списке доступных плагинов больше не отображается «Workflow Plugin», запустите Jenkins, перейдя в /restart и нажав «Да».

Простой поток

Давайте сделаем наш Workflow. Мы возьмем проект Jeff, созданный в первой части, и построим его как Workflow.

Для начала зайдите в панель инструментов Jenkins и нажмите «Новый элемент». Назовите новый элемент «Shell Test (Workflow)» и выберите тип Workflow.

Нажмите «ОК», чтобы создать новый проект. Вы попадете на страницу конфигурации проекта.

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

В разделе «Рабочий поток» находится текстовое поле с надписью «Сценарий». Именно здесь вы будете определять сценарий Workflow, который будет выполняться Jenkins, когда он инициализирует сборку проекта.

«Какой тип сценария?» Спросите вы. Отличный вопрос. Плагин Jenkins Workflow использует для скриптов язык Groovy. Groovy - это универсальный скриптовый язык для JVM. Не волнуйтесь, вам не нужно знать Groovy или Java, чтобы заставить все работать - плагин Jenkins Workflow использует небольшую DSL поверх Groovy, и очень легко комбинировать команды для создания рабочего процесса вашего проекта.

Идем дальше и добавляем в окно сценария следующее:

1	node {
2	git 'https://github.com/redhotvengeance/hello-jenkins.git'
3	sh 'uptime'
4	}

Так что здесь происходит?

Прежде всего, мы открываем блок node. Node - это место, где происходят действия Workflow. При назначении node создается новое рабочее пространство (контекст / папка). Весь код внутри блока node выполняется внутри этого рабочего пространства. Это помогает гарантировать, что шаги сборки не загрязняют друг друга.

Затем мы запускаем команду Git git 'https://github.com/redhotvengeance/hello-jenkins.git'. Эта команда клонирует Git репозиторий в наше рабочее пространство.

Наконец, мы говорим Workflow о выполнении команды оболочки uptime с sh' uptime.

Нажмите «Сохранить», и вы попадете на целевую страницу проекта. В левом меню находится кнопка «Собрать сейчас». Нажмите на нее, чтобы начать сборку.

Как только сборка будет завершена, нажмите на сборку #1, найденную в разделе «История сборки». Затем нажмите «Консольный вывод» в левом меню.

Здесь мы можем увидеть все, что было записано во время сборки. Она началась с выделения node в рабочей области «Shell Test (Workflow)». Затем он стунял Git репозиторий. Наконец, он выполнил команду uptime, которая печатала статистику времени безотказной работы сервера.

Вот и все! Мы теперь воссоздали те же шаги, что и обычная настройка проекта Jenkins в первой части, за исключением того, что это был рабочий процесс. Теперь давайте использовать те же самые концепции, чтобы сделать что-то более сложное.

Подделайте это, пока не сделаете это

Прежде чем мы сможем создать наш сложный Workflow, нам нужна работа, которая пройдет через него. Поддельный проект (ы) на помощь!

Поскольку мы уже используем Groovy для написания нашего Workflow, давайте использовать Gradle для наших поддельных проектов. Gradle - это система сборки, которая использует Groovy (удивительно, я знаю!). Чтобы использовать Gradle, нам нужно установить его на нашем сервере. SSH на ваш сервер (проверьте часть Джеффа, если что-то забыли) и запустите:

1	sudo apt-get install gradle

Двигаемся дальше.

Мы будем использовать два репозитория в нашем новом Workflow. Первый - строитель. Наш проект строителя очень прост: в нем есть скрипт сборки Gradle со следующим кодом:

1	task createBuild << {
2	new File("built.txt").write("You cannot pass.\n")
3	}

Так что здесь происходит? Gradle работает, выполняя «задачи», а скрипт сборки Gradle определяет эти задачи. Мы определили задачу, называемую createBuild, и что она делает, это создать текстовый файл с именем build.txt со следующим содержимым:

Вы не пройдете.

Это оно. (Хорошо, я говорил, что это было просто!)

Второй Git-репо - наш упаковщик. У упаковщика также есть скрипт сборки Gradle, но он немного сложнее:

task createPackage << {
  String packageText = "I am a servant of the Secret Fire, wielder of the flame of Anor. You cannot pass. The dark fire will not avail you, flame of Udûn. Go back to the Shadow!"
  String builtText = new File('built.txt').text
  new File("package.txt").write(packageText + "\n\n" + builtText)
}

Задача createPackage также создает текстовый файл (называемый package.txt), но он рассчитывает использовать контент из файла build.txt, которого нет в репозитории упаковщика. Если в репо существовал build.txt, сгенерированный файл package.txt содержал бы:

Я слуга Секретного Огня, обладателя пламени Анора. Вы не можете пройти. Темный огонь не поможет вам, пламя Удэна. Вернитесь к Тени!

Вы не можете пройти.

Если build.txt отсутствует, наша задача createPackage выдает ошибку.

Поэтому каждый раз, когда мы создаем наш упаковщик, нам нужно сначала запустить наш построитель и сделать полученный build.txt доступным для упаковщика, чтобы он мог создавать package.txt.

И это именно то, для чего мы будем создавать Jenkins Workflow!

Пусть поток работ через вас

Подойдите к панели инструментов Jenkins, нажмите «Новый элемент», назовите его «Ассемблер», выберите «Рабочий процесс» и нажмите «ОК».

Давайте начнем писать сценарии. Во-первых, как и раньше мы откроем блок node:

1	node {
2
3	}

Затем давайте склонируем репозиторий нашего строителя:

1	node {
2	git 'https://github.com/redhotvengeance/jenkins-workflow-build.git'
3	}

Теперь нам нужно запустить скрипт сборки Gradle для создания файла build.txt:

1	node {
2	git 'https://github.com/redhotvengeance/jenkins-workflow-build.git'
3	sh 'gradle createBuild'
4	}

Наконец, надо удостовериться, что все работает так, как мы ожидаем. Мы добавим cat, чтобы распечатать содержимое файла build.txt:

node {
  git 'https://github.com/redhotvengeance/jenkins-workflow-build.git'
  sh 'gradle createBuild'
  sh 'cat ./built.txt'
}

Нажмите «Сохранить», а затем запустите сборку. Как только это будет сделано, взгляните на вывод консоли.

Отлично! Мы успешно клонируем репозиторий, запускаем задачу createBuild и подтверждаем, что содержимое build.txt содержит строку You cannot pass.. Теперь об упаковщике.

Как и у строителя, нам нужно клонировать наш репозиторий. Давайте добавим код упаковщика:

node {
  git 'https://github.com/redhotvengeance/jenkins-workflow-build.git'
  sh 'gradle createBuild'
  sh 'cat ./built.txt'
}

node {
  git 'https://github.com/redhotvengeance/jenkins-workflow-package.git'
  sh 'gradle createPackage'
  sh 'cat ./package.txt'
}

Поскольку мы явно не создавали новое рабочее пространство, задача createPackage будет работать в том же рабочем пространстве, что и задание createBuild, что означает, что файл build.txt, ожидаемый от него, будет доступен для него.

Идем дальше, а нажимаем Сохранить и Собрать сейчас, а затем просмотрим вывод консоли.

Все выполнилоась, как ожидалось, - наш строитель был клонирован и выполнился, и наш упаковщик был клонирован и тоже выполнился. И если мы посмотрим на результат - вот оно! «Балрог Моргот» был полностью Гэндальфом.

Круто! но разве это немного не ...

Надумано? Вероятнее всего.

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

Что, если вместо диалога Гэндальфа выходы сборки были исполняемыми файлами из отдельных кодовых баз, которые все должны собираться вместе для программного обеспечения, которое вы отправляете? Вы должны использовать тот же рабочий процесс, который мы создали здесь: клонирование, создание, копирование и упаковка. С плагином Jenkins Workflow все, что нужно, это несколько строк Groovy. И в качестве бонуса все содержится в одном скрипте!

Существуют также другие инструменты для управления и визуализации рабочего процесса Jenkins. CloudBees предлагает функцию просмотра рабочего процесса на своей корпоративной платформе Jenkins.

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

Удачи с вашими процессами!