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

1. Въведение

В тази статия ще разгледаме различни начини за планиране на работни места в Дженкинс.

Ще започнем с планиране на проста работа, която изпълнява нещо толкова просто като отпечатване на обикновено текстово съобщение. И ще развием примера в планиране на работа, която автоматично се задейства от промени в SCM хранилище като GitHub, Bitbucket и т.н.

2. Първоначална настройка

Предполагаме, че JDK и Maven са инсталирани в Global Tool Configuration с имена като JDK9.0.1 и Maven3.5.2 , съответно, на сървъра на Jenkins.

Той също така предполага, че имаме достъп до хранилище на SCM като Bitbucket с правилно настроен проект на Maven.

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

В страницата на конфигурацията на работа, нека да превъртите надолу право към Build тригери секция. Тъй като възнамеряваме да създадем проста работа, нека поставим отметка в квадратчето Периодично изграждане . Веднага щом поставим отметка в това квадратче, се показва текстово поле с етикета Schedule .

Трябва да предоставим стойност във формат, съвместим с Cron . На страницата е налична обширна информация, ако щракнем върху въпросителния знак до полето.

Нека напишем * / 2 * * * * тук, което представлява интервал от две минути:

При излизане от текстовото поле можем да видим информация точно под полето. Той ни казва за това кога работата ще продължи следващата.

Нека запазим заданието - след около две минути трябва да видим състоянието на първото изпълнение на заданието:

Тъй като сме конфигурирали заданието да се изпълнява на всеки две минути, трябва да видим множество номера на компилация, когато се върнем на таблото за работа, след като изчакаме известно време.

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

Нека се придвижим с една крачка напред и да създадем работа, която изтегля изходния код от хранилището на SCM като Bitbucket и изпълнява компилация.

Нека създадем нова работа, както е обяснено в предишния раздел, с няколко модификации.

В раздела Изграждане на задействания , вместо да избираме Периодично изграждане , нека да изберете Poll SCM . Веднага след като направим това, трябва да видим текстово поле с График на етикетите .

Нека напишем * / 5 * * * * в това поле, което означава, че искаме да планираме работата да се изпълнява на всеки 5 минути:

Нека да превъртим до раздела Управление на изходния код . След като изберете радио бутона до Git , се появява нов раздел, обозначен като хранилища .

Тук трябва да конфигурираме подробности за нашето хранилище на SCM . Нека въведем URL адреса на хранилището на SCM в текстовото поле на URL адреса на хранилището :

Също така трябва да предоставим потребителски идентификационни данни, така че Дженкинс да има достъп до хранилището.

Нека щракнем върху бутона Добавяне до идентификационни данни, който ще покаже изскачащ екран за създаване на потребителски идентификационни данни.

Нека да изберем вида като потребителско име с парола . Ще трябва да въведем потребителското име и паролата в определените текстови полета:

При щракване върху бутона Добавяне се връщаме към раздела за управление на изходния код .

Нека изберете тази потребителска идентификация в падащото меню до Удостоверения :

Сега, последното нещо, което трябва да направим, е да настроим скрипта за изграждане.

Нека да превъртите надолу, за да Build раздел, щракнете върху Добавяне на натрупване стъпка и изберете Execute Shell . Тъй като работим по проект на Maven в хранилището на SCM, трябва да напишем mvn clean install , който ще изпълни компилация на Maven.

Нека се опитаме да разберем какво сме направили тук.

Създадохме работа, която трябва да се изпълнява на всеки 5 минути. Заданието е конфигурирано да изтегля изходния код от главния клон на даденото хранилище на Bitbucket .

Той ще използва предоставените потребителски идентификационни данни, за да влезе в Bitbucket.

След издърпване на изходния код, заданието ще изпълни скрипта, съдържащ предоставена команда Maven.

Сега, ако запазим и изчакаме около пет минути, трябва да видим изпълнението на компилацията в раздела „ История на компилациите “ на таблото за управление на заданието.

На изхода на конзолата трябва да покаже продукцията на изграждането Maven. В изхода на конзолата можем да видим, че изходният код е изтеглен от Bitbucket и е изпълнена командата mvn clean install :

Тъй като това е компилация на Maven, изходът на конзолата може да е много дълъг в зависимост от броя на изтеглените зависимости на Maven .

Но в края на изхода трябва да видим съобщението BUILD SUCCESS .

5. Създаване на работа, която използва тръбопровод като скрипт

Досега видяхме как да създаваме работни места, които се изпълняват в предварително зададения график.

Сега нека създадем работа, която не е обвързана с някакъв конкретен график. Вместо това ще го конфигурираме да се задейства автоматично, когато има ново фиксиране в хранилището на SCM.

Връщайки се към таблото за управление на Jenkins, нека щракнем върху New Item . Този път вместо проект Freestyle ще изберем Pipeline . Нека наречем тази работа PipelineAsScriptJob.

Upon clicking OK button, we'll be taken to the pipeline configuration page. This page has several sections such as “General”, “Build Triggers”, “Advanced Project Options”, and “Pipeline”.

Let's scroll down to “Build Triggers” section and the select checkbox next to Build when a change is pushed to Bitbucket. This option will be available only if we've installed the Bitbucket Plugin:

Let's scroll down to Pipeline section. We need to select Pipeline Script in the drop-down next to Definition.

The Text Box just below this drop-down is waiting for the script to be placed in. There're two ways of doing this.

We can either type the whole script, or we can make use of a utility provided by Jenkins, which is known as Pipeline Syntax.

Let's choose the second option:

On click of Pipeline Syntax, as highlighted in the diagram above, a new tab opens up in the browser. This is a handy utility where we can specify the operation that we wish to perform, and the tool will generate the script in Groovy for us. We can then copy the script and paste it into the pipeline configuration.

Let's select checkout: General SCM in the Sample Step drop-down. After providing the SCM Repo URL and user credentials, we need to click the Generate Pipeline Script button.

This generates the script in the text box:

Let's copy this script and save it somewhere for later use.

On the same page, let's scroll up and select withMaven: Provide Maven environment in the Sample Step drop-down. It must be noted here, that this option will be available only if Pipeline Maven Integration Plugin is installed.

We need to select the names of Maven and JDK installations next to the corresponding drop-downs. We need to click the Generate Pipeline Script button.

This generates the script in the text box:

Let's save the script.

There are still a few more scripts that we need to generate. Let's select node: Allocate node in the Sample Step drop-down, type master in the Label text field and click Generate Pipeline Script:

Let's save the script.

And last one.

Let's select stage: Stage in the Sample Step drop-down, type scm in the Stage Name text field and click Generate Pipeline Script:

Let's save it.

It's time to collate all the scripts generated so far and stitch them together:

node('master') { stage('scm') { checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'e50f564f-fbb7-4660-9c95-52dc93fa26f7', url: '//[email protected]/projects/springpocrepo.git']]]) } stage('build') { withMaven(jdk: 'JDK9.0.1', maven: 'Maven3.5.2') { sh 'mvn clean install' } } }

The first statement, node(‘master') in the script above, indicates that the job will be executed on a node named master, which is the default node on the Jenkins server.

Let's copy the above script to the Text Box in Pipeline section:

Let's save this configuration.

Now, there's only one thing that's left out. We need to configure a Webhook in Bitbucket. The Webhook is responsible for sending out a push notification to Jenkins server, whenever a particular event takes place in Bitbucket.

Let's take a look at how to configure it.

Let's log in to Bitbucket and select a repository. We should see an option Settings on the left-hand side column. Let's click it, and we should see an option Webhooks in WORKFLOW section. Let's create a new Webhook.

We need to provide some name to this webhook in the Title field. We also need to provide a URL for the webhook in the URL field. This URL needs to point to one particular REST API Endpoint provided by Jenkins, and that endpoint is bitbucket-hook.

It must be noted that the URL MUST end with a trailing slash:

While configuring the Webhook above, we've selected option Repository push. This means Bitbucket will send a notification to Jenkins server whenever a push happens.

This behavior can be modified; there are several different options to choose from.

For now, let's go with the default option,i.e., Repository Push.

We can setup webhook in Github, too; here‘s some helpful information on how to configure that.

Long story short: we've created a pipeline script in Groovy language – that should pull the source code from the master branch of the provided SCM repository (using the provided user credentials), whenever there's a push in the repository and then execute mvn clean install command on the Jenkins server.

It must be noted that this job's not going to run at any particular time. Instead, it's going to wait till there's a push in the master branch of the SCM repository.

As soon as there's a new push event, we'll see a new execution in the “Build History” section on the Jenkins job dashboard.

We should see a new build being initiated with a pending status next to it.

In a few seconds, this build should start execution, and we'll be able to see the complete log in Console Output.

The first statement in the console output says “Started by Bitbucket push by..” – this means that the build was triggered automatically when a Push took place in Bitbucket:

If all goes well, the build should complete successfully.

6. Create a Job That Uses Jenkinsfile

It's possible NOT to write any script in the Jenkins pipeline and still achieve build execution being triggered by the Bitbucket Webhook.

To do so, we have to create a new file in Bitbucket and name it as Jenkinsfile. The pipeline script needs to be transferred to this Jenkinsfile with a slight modification. Let's see exacttly how to do that.

We'll create a new pipeline in Jenkins and name it PipelineWithJenkinsfile.

On the pipeline configuration page, we'll select Pipeline script from SCM next to Definition in the Pipeline section. We'll see a drop-down with different options next to SCM. Let's choose Git from the drop-down.

We then have to provide the URL of Bitbucket repository and user credentials. Let's ensure that the text field next to Script Path contains the default value,i.e., Jenkinsfile:

As far as Jenkins is concerned, that's all we need to configure.

However, we have to create the Jenkinsfile in the repository; so, let's create a new text file, name it as Jenkinsfile and use this simple groovy script:

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

This script is almost the same as the pipeline script that we created in the earlier section, with just one modification. The statement in stage(‘scm') doesn't need the URL and user credentials information. Instead, all it needs is checkout scm.

And that's it. The moment we commit this file into Bitbucket, it'll trigger the build in Jenkins – and we should see the build being triggered in the Build History.

The only difference between this section and the earlier one is that we defined the pipeline script in the Bitbucket repository.

И така, скриптът за изграждане е част от изходния код на проекта, който трябва да бъде изграден . Не поддържаме сценария в самия Дженкинс.

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

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

В този урок видяхме как задачите могат да бъдат конфигурирани и насрочени в Дженкинс с помощта на различни стратегии.

Видяхме също как да конфигурираме работа в Jenkins, така че тя да се задейства автоматично, въз основа на определени действия, извършени в хранилището на SCM, като Bitbucket.