Jenkins came with a big bang. That said, it enhanced the whole process of continuous integration & continuous deployment.
The challenge that a dev faces is to deliver the most updated and safe code to the customer. The advent of CD(continuous deployment) pipeline automates expression of the process to get the software from the version control system directly to the user.
This expression, which does it so fluently as we speak, is what a Jenkins file constitutes.
Introduction
Jenkins is an open source automation server written in Java. Jenkins helps to automate the non-human part of the software development process, with continuous integration and facilitating technical aspects of continuous delivery.
So the next part is about how we can achieve that.
Pipelines
Jenkins Pipeline is a suite of plugins which supports implementing and integrating continuous delivery pipelines into Jenkins.
Plugins have been released for Jenkins that extend its use to projects written in languages other than Java. Plugins are available for integrating Jenkins with most version control systems and bug databases. Many build tools are supported via their respective plugins. Builds can generate test reports in various formats supported by plugins (JUnit support is currently bundled) and Jenkins can display the reports and generate trends and render them in the GUI.
A CD pipeline:
automates expression of getting the software from VCS(git).
contains stages of continuous delivery from which the software must go through before the user handles it.
are extensible by tools for modeling simple-to-complex delivery pipelines.
The Jenkinsfile
A simple text file containing the definition of the pipeline. This jenkinsfile can be committed to the project’s source. It is advantageous because it allows for the following advantages:
- automatically creates a pipeline for each branch and PR(pull request).
- code review of the pipeline can be done.
- can be viewed and edited by other users also.
Flavors of jenkinsfile
Jenkinsfile can be defined in 2 different ways. First, which is the oldest way and quite popular in the community, is the Scripted Pipeline syntax. The other, which is the new ‘hot stepper’ in the field and has an edge over the former, is the Declarative pipeline.
Though the syntax of both the flavors doesn’t differ from each other the Declarative pipeline is made to make writing and reading the pipeline code much easier.
Before we dig into the practicality of pipelines let’s see why they are needed in the first place. There are 5 points by which we can understand the need:
- CODE: the pipeline becomes the part of the project source, therefore, can be viewed, reviewed and changed as per the need.
- DURABLE: pipeline executes whenever there is a new commit message in the project source, hence allowing it to survive both planned and unplanned starts.
- PAUSABLE: pipelines can also wait for human interaction and plan the task accordingly.
- VERSATILE: pipelines can also perform work in parallel and can implement the real-world CD requirements easily.
- EXTENSIBLE: supports plugins which make even the Jenkins GUI better.
Now that we know the need of pipeline. Let’s see how it is made.
pipeline {
agent any
stages {
stage('Build') {
steps {
//
}
}
stage('Test') {
steps {
//
}
}
stage('Deploy') {
steps {
//
}
}
}
}
Let’s take a look at the various elements of the pipeline defined above.
Sections of the declarative pipeline:
agent: section specifies where the entire Pipeline, or a specific stage, will execute in the Jenkins environment. Agent option can be specified for each stage.
values: any: executing the pipeline on any available agent. This tag has more meaning when we consider the situation where we have several instances.
stages: This section specifies the stages from which the software needs to pass through before the user gets to use it.
stage: This section is the subsection of the Stages section. Each section must have the which denotes the name of the process, in case it fails.
There goes the introduction. Let’s move towards creating jenkinsfile for our own repository. Here to demonstrate I have a java project which consists of classes and test cases with integrated stylesheet by which we can check the syntactical mistakes.
Since we are going to put the jenkinsfile directly to the source. If you don’t have the repository locally, please clone your repo first.
Process
Step: 1 Create A jenkinsfile.
Open the terminal in your java project folder and hit this command:
>gedit jenkinsfile
or
>vi jenkinsfile
Although there are a lot of editors which will help you in creating the jenkinsfile, for now, you can use your text editor. Jenkinsfile uses the groovy notation but it isn’t necessary to have an understanding of the syntax. This file can also be created by IntelliJ while you develop your project. Let’s put the following content in the jenkinsfile:
pipeline{
stages{
stage('checkstyle'){
//
}
stage('run test cases'){
//
}
}
}
Now that we have created a backbone of our jenkinsfile by defining the stages. Now we need to insert content inside these stages to carry out just what it says.
Now we need to insert tools section. Tools section defining tools to auto-install and put to PATH. This is ignored if agent none is specified. PATH contains the name of the directory within Jenkins.
We require two tools. First is Maven to execute checkstyle and test and Second is Java Development Kit version 8. But before putting this information in our jenkinsfile. We need to add these tools to Jenkins.
Step: 2 Adding the tools to Jenkins.
Go to Managing Jenkins -> Global Tool Configurations.
To add JDK: Click on Add JDK button. Put the name as ‘jdk8’. Click on install automatically. Select the Java version 8 and check I agree.
Click on the username and password and put in the credentials of your Jenkins account.
To add Maven: Same procedure as above. Put the name as ‘Maven 3.3.9’ and also select the same version.
After we’re done with this we can now use them easily.
Step 3: Adding the tool section in jenkinsfile.
...
tools {
maven 'Maven 3.3.9'
jdk 'jdk8'
}
...
Now we will update the stages with the appropriate commands.
For the checkstyle stage, we will put in something like this.
steps{
sh 'mvn checkstyle:checkstyle'
}
sh here resembles the command prompt, we only need to specify the command as we do on our local console. Similarly, the testing stage can be updated with an appropriate command.
Step 4: Commit the jenkinsfile to your Github repository.
Step 5: Creating the item and build.
Go to the Dashboard.
Click on New Item. Put in the name of the Pipeline project. Click OK.
Click on the Pipeline panel. On the definitions select Pipeline script from SCM
Select SCM as git.
On the Repositories section. Put your GitHub URL at repository URL.
Script Path must contain the location of your jenkinsfile in the repository.
Do not use the path from your local machine.
Click on apply and save.
For building, Click on Build Now and wait for a while.
Output
You will have the following output which will depict the stages.
Understanding the process
Declarative steps are done prior to executing user-specified step. In these steps, the first task to be done is to pull the repository to Jenkins and then tools are installed accordingly as specified by the user. Installation of tools may take some time if done for the first time.
I hope you find the blog helpful.
1 thought on “Jenkins File: The A B C …6 min read”
Comments are closed.