TOC

Планирование работы в Дженкинс

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 периодически . Как только мы установим этот флажок, появится текстовое поле с меткой Schedule .

  • Мы должны предоставить значение в ссылке:/cron-expressions[Cron-совместимый формат]** . На странице доступна обширная информация, если щелкнуть знак вопроса рядом с полем.

Давайте напишем здесь /2 ** , что соответствует интервалу в две минуты

ссылка:/uploads/build-triggers-section.png%201227w[]

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

Давайте сохраним работу - примерно через две минуты мы должны увидеть статус первого выполнения задания:

ссылка:/uploads/job-status-1.png%20798w[]

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

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

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

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

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

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

ссылка:/uploads/poll-scm.png%201200w[]

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

  • Здесь нам нужно настроить детали нашего репозитория SCM ** .

Давайте наберем URL-адрес хранилища SCM в текстовом поле Repository URL :

ссылка:/uploads/poll-scm-source-code-management-empty.png%201183w[]

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

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

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

ссылка:/uploads/AddUser-1.png%201402w[]

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

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

ссылка:/uploads/SourceCodeManagement-2.png%201172w[]

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

Прокрутите вниз до раздела Build , нажмите Add build step и выберите Execute Shell . Поскольку мы работаем над проектом Maven в репозитории SCM, нам нужно ввести mvn clean install , который будет выполнять сборку Maven.

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

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

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

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

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

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

ссылка:/uploads/maven-console-output-1-1-768x362.png%20768w[]

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

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

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

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

Теперь давайте создадим работу, которая не связана с каким-либо конкретным графиком.

Вместо этого мы настроим его на автоматический запуск при появлении нового коммита в репозитории SCM.

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

После нажатия кнопки ОК мы попадем на страницу конфигурации конвейера. На этой странице есть несколько разделов, таких как « General» , « Build Triggers» , « Advanced Project Options» и « Pipeline» .

Прокрутите вниз до раздела « Build Triggers» и установите флажок рядом с « Build», когда изменение помещается в Bitbucket . Эта опция будет доступна, только если мы установили плагин Bitbucket :

ссылка:/uploads/pipeline-script-build-triggers-section.png%201199w[]

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

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

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

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

ссылка:/uploads/pipeline-syntax-link.png%201212w[]

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

Давайте выберем checkout: General SCM в раскрывающемся списке Sample Step .

После предоставления URL-адреса репозитория SCM и учетных данных пользователя нам нужно нажать кнопку Generate Pipeline Script .

Это создает сценарий в текстовом поле:

ссылка:/uploads/pipeline-script-checkout-syntax-1.png%201563w[]

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

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

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

Это создает сценарий в текстовом поле:

ссылка:/uploads/pipeline-script-withMaven-syntax.png%201506w[]

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

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

ссылка:/uploads/pipeline-node-syntax.png%201502w[]

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

И последний.

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

ссылка:/uploads/pipeline-script-stage-syntax-1.png%201450w[]

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

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

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

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

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

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

ссылка:/uploads/pipeline-script-all-together.png%201208w[]

Давайте сохраним эту конфигурацию.

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

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

Давайте войдем в Bitbucket и выберем репозиторий. Мы должны увидеть параметр Settings в левой колонке. Давайте щелкнем по нему, и мы увидим параметр Webhooks в разделе WORKFLOW . Давайте создадим новый Webhook.

Нам нужно указать какое-то имя этому webhook в поле Title . Мы также должны предоставить URL для webhook в поле URL . Этот URL-адрес должен указывать на одну конкретную конечную точку API REST, предоставленную Jenkins, и этой конечной точкой является bitbucket-hook .

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

ссылка:/uploads/Webhook-1-1.png%201340w[]

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

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

А сейчас давайте перейдем к варианту по умолчанию, т.е. Repository Push .

  • Мы также можем настроить webhook в Github ** ; here - некоторая полезная информация о том, как это настроить.

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

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

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

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

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

  • Первый оператор в выводе консоли гласит «Запущено с помощью Bitbucket push by ..» - ** это означает, что сборка была запущена автоматически, когда в Bitbucket произошла Push:

ссылка:/uploads/pipeline-script-console-output-1-1-768x370.png%20768w[]

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

6. Создать работу, которая использует Jenkinsfile

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

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

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

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

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

ссылка:/uploads/jenkinsfile-pipeline-config-2.png%201358w[]

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

Тем не менее, мы должны создать 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 - и мы должны увидеть, как сборка запускается в Build History

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

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

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

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

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

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

Related