Перейти к основному содержимому

Как планировать задачи в Jenkins?

· 10 мин. чтения

1. Введение

В этой статье мы рассмотрим различные способы планирования заданий в Jenkins.

Мы начнем с планирования простого задания, которое выполняет такую простую задачу, как печать простого текстового сообщения. И мы расширим этот пример до планирования задания, которое автоматически запускается изменениями в репозитории SCM, таком как GitHub, Bitbucket и т. д.

2. Первоначальная настройка

Мы предполагаем, что JDK и Maven были установлены в Global Tool Configuration с именами JDK9.0.1 и Maven3.5.2 соответственно на сервере Jenkins.

Также предполагается, что у нас есть доступ к репозиторию SCM , такому как Bitbucket, с правильно настроенным проектом Maven.

3. Планирование простой работы

На странице конфигурации задания давайте прокрутим вниз прямо до раздела Build Triggers . Поскольку мы намерены создать простую работу, давайте установим флажок с пометкой Build периодически . Как только мы установим этот флажок, появится текстовое поле с меткой « Расписание ».

Мы должны предоставить значение в формате, совместимом с Cron . На странице доступна обширная информация, если щелкнуть знак вопроса рядом с полем.

Введите здесь */2 * * * * , что представляет интервал в две минуты:

./1323ab1daf0321b44e52f40848aea6e0.png

При выходе из текстового поля мы можем видеть информацию прямо под полем. Он сообщает нам о том, когда задание будет запущено в следующий раз.

Сохраним задание — примерно через две минуты мы должны увидеть статус первого выполнения задания:

./7edf071933ff7f73a1acd4fb45d14b1b.png

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

4. Создание задания, которое опрашивает SCM

Давайте сделаем еще один шаг вперед и создадим задание, которое извлекает исходный код из репозитория SCM, такого как Bitbucket, и выполняет сборку.

Давайте создадим новое задание, как описано в предыдущем разделе, с некоторыми изменениями.

В разделе Build Triggers вместо выбора Build Periodically выберем Poll SCM . Как только мы это сделаем, мы должны увидеть текстовое поле с Label Schedule .

Введите */5 * * * * в это поле, что означает, что мы хотим запланировать запуск задания каждые 5 минут:

./0f713d3bfd602d62d43cb161ddb3872e.png

Давайте прокрутим вверх до раздела « Управление исходным кодом ». После выбора переключателя рядом с Git появится новый раздел, помеченный как Repositories .

Здесь нам нужно настроить детали нашего репозитория SCM . Введите URL-адрес репозитория SCM в текстовое поле URL -адрес репозитория:

./da941d897799efaa4a443017eaf2ed2a.png

Нам также необходимо предоставить учетные данные пользователя, чтобы Дженкинс мог получить доступ к репозиторию.

Давайте нажмем кнопку « Добавить » рядом с «Учетные данные», которая отобразит всплывающее окно для создания учетных данных пользователя.

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

./e63f95ff23a3ccee4190722a59aac9ba.png

При нажатии кнопки « Добавить » мы возвращаемся в раздел « Управление исходным кодом ».

Давайте выберем эти учетные данные пользователя в раскрывающемся списке рядом с Credentials :

./bc1b4a7d7a326e77d5e7ff338f7de603.png

Теперь последнее, что нам нужно сделать, это настроить скрипт сборки.

Давайте прокрутим вниз до раздела « Сборка », нажмите « Добавить шаг сборки » и выберите « Выполнить оболочку » . Поскольку мы работаем над проектом Maven в репозитории SCM, нам нужно ввести mvn clean install , который выполнит сборку Maven.

Давайте попробуем понять, что мы здесь сделали.

Мы создали задание, которое планируется запускать каждые 5 минут. Задание настроено на извлечение исходного кода из главной ветки данного репозитория Bitbucket .

Он будет использовать предоставленные учетные данные пользователя для входа в Bitbucket.

После извлечения исходного кода задание выполнит сценарий, содержащий предоставленную команду Maven.

Теперь, если мы сохраним и подождем примерно пять минут, мы должны увидеть выполнение сборки в разделе «История сборки » на панели задач.

Выходные данные консоли должны отображать выходные данные сборки Maven. В выводе консоли мы видим, что исходный код был извлечен из Bitbucket и выполнена команда mvn clean install :

./6e3be91ffd0b6fa3e965c2d2839caa0d.png

Поскольку это сборка Maven, вывод консоли может быть очень длинным в зависимости от количества загруженных зависимостей Maven .

Но в конце вывода мы должны увидеть сообщение BUILD SUCCESS .

5. Создание задания, использующего пайплайн в качестве скрипта

До сих пор мы видели, как создавать задания, которые выполняются в заранее определенное запланированное время.

Теперь давайте создадим задание, которое не привязано ни к какому конкретному расписанию. Вместо этого мы настроим его на автоматический запуск всякий раз, когда в репозитории SCM появляется новая фиксация.

Вернувшись к панели инструментов Jenkins, давайте нажмем New Item . На этот раз вместо Freestyle project мы выберем Pipeline . Назовем это задание PipelineAsScriptJob.

После нажатия кнопки «ОК» мы попадем на страницу конфигурации конвейера. На этой странице есть несколько разделов, таких как « Общие» , « Триггеры сборки» , « Дополнительные параметры проекта» и « Конвейер» .

Давайте прокрутим вниз до раздела « Триггеры сборки» и установим флажок рядом с пунктом « Сборка», когда изменение передается в Bitbucket . Эта опция будет доступна, только если мы установили плагин Bitbucket :

./98a855085dfdc5fa9beb7ecf939150a3.png

Давайте прокрутим вниз до раздела Pipeline . Нам нужно выбрать Pipeline Script в раскрывающемся списке рядом с Definition .

Текстовое поле чуть ниже этого раскрывающегося списка ожидает размещения скрипта. Есть два способа сделать это.

Мы можем либо ввести весь скрипт целиком, либо воспользоваться утилитой, предоставленной Jenkins, известной как Pipeline Syntax .

Выберем второй вариант:

./0d9ea58d8287cac2cb7fd81a1e8173a6.png

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

Давайте выберем checkout: General SCM в раскрывающемся списке Sample Step . После предоставления URL-адреса репозитория SCM и учетных данных пользователя нам нужно нажать кнопку « Создать скрипт конвейера » .

Это генерирует скрипт в текстовом поле:

./945450bb48120f1c72d834413d60eeae.png

Давайте скопируем этот скрипт и сохраним его где-нибудь для дальнейшего использования.

На той же странице давайте прокрутим вверх и выберем withMaven: Предоставить среду Maven в раскрывающемся списке Sample Step . Здесь следует отметить, что эта опция будет доступна только в том случае, если установлен плагин интеграции Pipeline Maven .

Нам нужно выбрать имена установок Maven и JDK рядом с соответствующими раскрывающимися списками. Нам нужно нажать кнопку Generate Pipeline Script .

Это генерирует скрипт в текстовом поле:

./ac6905eea4868c623f11786c14fe502e.png

Сохраним скрипт.

Нам нужно сгенерировать еще несколько скриптов. Давайте выберем node: Allocate node в раскрывающемся списке Sample Step , введите master в текстовом поле Label и нажмите Generate Pipeline Script :

./5dd173cf7a5d96fb58206439aae16583.png

Сохраним скрипт.

И последний.

Давайте выберем этап: Stage в раскрывающемся списке Sample Step , введите scm в текстовом поле Stage Name и нажмите Generate Pipeline Script :

./e455cb94cd2ceacd8ba7c49a97d391c0.png

Давайте сохраним его.

Пришло время сопоставить все сгенерированные скрипты и соединить их вместе:

node('master') {
stage('scm') {
checkout([$class: 'GitSCM',
branches: [[name: '*/master']],
doGenerateSubmoduleConfigurations: false,
extensions: [],
submoduleCfg: [],
userRemoteConfigs: [[credentialsId: 'e50f564f-fbb7-4660-9c95-52dc93fa26f7',
url: 'https://developer@bitbucket.org/projects/springpocrepo.git']]])
}

stage('build') {
withMaven(jdk: 'JDK9.0.1', maven: 'Maven3.5.2') {
sh 'mvn clean install'
}
}
}

Первый оператор node('master') в приведенном выше сценарии указывает, что задание будет выполняться на узле с именем master , который является узлом по умолчанию на сервере Jenkins.

Давайте скопируем приведенный выше скрипт в текстовое поле в разделе Pipeline :

./c41cdb7a3aea820a1085983497e3b05a.png

Сохраним эту конфигурацию.

Теперь осталось только одно. Нам нужно настроить Webhook в Bitbucket. Webhook отвечает за отправку push-уведомлений на сервер Jenkins всякий раз, когда в Bitbucket происходит определенное событие .

Давайте посмотрим, как его настроить.

Давайте войдем в Bitbucket и выберем репозиторий. Мы должны увидеть опцию « Настройки » в левой колонке. Щелкнем по нему, и мы должны увидеть опцию Webhooks в разделе WORKFLOW . Создадим новый вебхук.

Нам нужно указать какое-то имя для этого веб-перехватчика в поле « Заголовок » . Нам также необходимо указать URL-адрес веб-перехватчика в поле URL . Этот URL-адрес должен указывать на одну конкретную конечную точку REST API, предоставленную Jenkins, и эта конечная точка — bitbucket-hook .

Следует отметить, что URL-адрес ДОЛЖЕН заканчиваться косой чертой :

./40dde6270c13548583a8bf0589e4578a.png

При настройке Webhook выше мы выбрали опцию Repository push . Это означает, что Bitbucket будет отправлять уведомления на сервер Jenkins всякий раз, когда происходит push .

Это поведение можно изменить; есть несколько различных вариантов на выбор.

На данный момент давайте выберем вариант по умолчанию, т . е. Repository Push .

Мы также можем настроить веб-хук в Github ; Вот некоторая полезная информация о том, как это настроить.

Короче говоря: мы создали сценарий конвейера на языке Groovy , который должен извлекать исходный код из основной ветки предоставленного репозитория SCM (используя предоставленные учетные данные пользователя) всякий раз, когда в репозитории есть толчок, а затем выполнять mvn clean установить команду на сервер Jenkins .

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

Как только появится новое push-событие, мы увидим новое выполнение в разделе «История сборки» на панели задач Jenkins.

Мы должны увидеть, что новая сборка инициируется со статусом ожидания рядом с ней.

Через несколько секунд эта сборка должна начать выполняться, и мы сможем увидеть полный журнал в выводе консоли .

Первый оператор в выводе консоли говорит: «Запущено путем отправки Bitbucket…» — это означает, что сборка была запущена автоматически, когда в Bitbucket была выполнена отправка:

./862476606301e85a90f73ffd65853ffc.png

Если все пойдет хорошо, сборка должна завершиться успешно.

6. Создайте задание, использующее Jenkinsfile

Можно НЕ писать какой-либо сценарий в конвейере Jenkins и по-прежнему добиваться выполнения сборки, запускаемого веб-перехватчиком Bitbucket.

Для этого нам нужно создать новый файл в Bitbucket и назвать его Jenkinsfile . Скрипт пайплайна нужно перенести в этот Jenkinsfile с небольшой модификацией. Давайте посмотрим, как именно это сделать.

Мы создадим новый конвейер в Jenkins и назовем его PipelineWithJenkinsfile .

На странице конфигурации конвейера мы выберем сценарий конвейера из SCM рядом с определением в разделе конвейер . Мы увидим раскрывающийся список с различными параметрами рядом с SCM . Давайте выберем Git из раскрывающегося списка.

Затем мы должны указать URL-адрес репозитория Bitbucket и учетные данные пользователя. Давайте удостоверимся, что текстовое поле рядом с Script Path содержит значение по умолчанию, то есть Jenkinsfile :

./18d517b72055b76985fb6424bbf498d7.png

Что касается Дженкинса, это все, что нам нужно настроить.

Однако нам нужно создать Jenkinsfile в репозитории; Итак, давайте создадим новый текстовый файл, назовем его Jenkinsfile и воспользуемся этим простым классным скриптом:

node('master') {
stage('scm') {
checkout scm
}
stage('build') {
withMaven(jdk: 'JDK9.0.1', maven: 'Maven3.5.2') {
sh 'mvn clean install'
}
}
}

Этот сценарий почти такой же, как сценарий конвейера, который мы создали в предыдущем разделе, с одной лишь модификацией. Оператору в stage('scm') не нужны данные URL и учетных данных пользователя. Вместо этого все, что ему нужно, это checkout scm .

Вот и все. В тот момент, когда мы зафиксируем этот файл в Bitbucket, он запустит сборку в Jenkins — и мы должны увидеть запуск сборки в истории сборки .

Единственная разница между этим разделом и предыдущим заключается в том, что мы определили скрипт конвейера в репозитории Bitbucket.

Итак, скрипт сборки — это часть исходного кода проекта, который необходимо собрать . Мы не поддерживаем сценарий в самом Дженкинсе.

Вместо этого Дженкинс знает детали репозитория SCM и файл сценария. Всякий раз, когда происходит отправка в этот репозиторий, скрипт в Jenkinsfile запускается на сервере Jenkins .

7. Заключение

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

Мы также увидели, как настроить задание в Jenkins, чтобы оно запускалось автоматически на основе определенных действий, выполняемых в репозитории SCM, таком как Bitbucket.