Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Use Basic Jenkins Pipelines

DZone's Guide to

How to Use Basic Jenkins Pipelines

Learn the steps to set up pipelines in Jenkins and build a basic pipeline, the basis for continuous integration and delivery in development.

· DevOps Zone ·
Free Resource

Learn how integrating security into DevOps to deliver "DevSecOps" requires changing mindsets, processes and technology.

Building a Jenkins Pipeline

With the introduction of the Pipeline, Jenkins added an embedded Groovy engine, making Groovy the scripting language in the Pipeline's DSL.

Here are the steps you need to take to set up a Jenkins Pipeline. You have to install a plugin, "Pipeline Plugin."

  1. First, log on to your Jenkins server and select “New Item” from the left panel.

  2. Next, enter a name for your pipeline and select “Pipeline” from the options. Click “Ok” to proceed to the next step.

  3. You can now start working your Pipeline script.

The red box in the middle is where you can start writing your script, which will be explained now.

Creating a Jenkins Pipeline Script

Pipelines have specific sentences or elements to define script sections, which follow the Groovy syntax.

Node Blocks

The first block to be defined is the “node”:

node {
}

A "node” is part of the Jenkins distributed mode architecture, where the workload can be delegated to multiple “agent” nodes.

A “master” node handles all the tasks in your environment. Jenkins agent nodes offloads builds from the master node, performing all the pipeline work specified in the node block. 

  • This block is optional, and could be considered a good practice with the code included in this block.
  • Jenkins will schedule and run all the steps once any node available and create a specific workspace directory.

For more details, you can read about Jenkins distributed builds.

Stage Section in Jenkins Pipeline Build

A “stage” section is required to segregate the work category, as listed inline:

stage {
}

The specified pipeline will consist of several steps that can be grouped in several stages. For example:

Pull code from repository

“Pull Code in Stage 1”

Build your project and artifacts

“build Project/Artifacts the project in Stage 2”

Deploy your application

“deploy from centralized repo to specified environ in Stage 3”

Perform functional tests

“QA section would define in stage 4”

Perform performance tests

UI and performance can test in stage 5


Note: Each of the these can include more than one action. For example, a stage to deploy your application can consist of copying the files to a defined environment for functional tests and a dedicated server for performance tests/QA, and once files are copied successfully, the delivery process will start to deploy on any specified environment.

Each stage block specifies the tasks to be performed. Stage blocks are also optional, but they are recommended because they provide an organized way of specifying tasks to be executed in the script.

The “Pipeline Syntax” section builds on the information introduced above and should be treated solely as a reference. For more information on how to use Pipeline syntax in practical examples, refer to the "Using a Jenkinsfile" section of the Jenkins chapter.

As of version 2.5 of the Pipeline plugin, Pipeline supports two discrete syntaxes which are detailed below. For the pros and cons of each, see the Syntax Comparison.

“Pipeline Syntax” is used to access the following page. “Generate Pipeline Script” will create the desired sentence that can be added to your script right away.

The Jenkinsfile

Pipeline supports two syntaxes, declarative (introduced in Pipeline 2.5) and scripted pipeline. Both support building continuous delivery pipelines. Both may be used to define a pipeline in either the web UI or with a Jenkinsfile, though it’s generally considered a best practice to create a Jenkinsfile and check the file into the source control repository.

Jenkins Declarative Pipeline:

pipeline {
 agent any
 stages {
  stage('Build') {
   steps {
    echo 'Building..'
   }
  }
  stage('Test') {
   steps {
    echo 'Testing..'
   }
  }
  stage('Deploy') {
   steps {
    echo 'Deploying....'
   }
  }
 }
}

Jenkins Scripted Pipeline:

node {
 checkout scm
 /* .. snip .. */
}

For more advanced usage with scripted pipelines, the example above node is a crucial first step as it allocates an executor and workspace for the pipeline. Since the Jenkinsfile is being pulled directly from source control, the pipeline provides a quick and easy way to access the right revision of the source code.

The checkout step will checkout code from source control; scm is a special variable which instructs the checkout step to clone the specific revision which triggered this pipeline run.

A Few Words About Security

To reduce manual interventions by administrators, most scripts will run in a Groovy Sandbox by default, including all Jenkins pipelines. The sandbox only allows a subset of Groovy’s methods deemed sufficiently safe for "untrusted" access to be executed without prior approval. Scripts using the Groovy Sandbox are all subject to the same restrictions, therefore a pipeline authored by an administrator is subject to the same restrictions as one authorized by a non-administrative user.

When a script attempts to use features or methods unauthorized by the sandbox, a script is halted immediately, as shown below with a Jenkins pipeline.

Image title

The above pipeline will not be executed until an administrator approves it.

In addition to adding approved method signatures, users may also disable the Groovy Sandbox entirely. Disabling the Groovy Sandbox requires that the entire script be reviewed and manually approved by an administrator.

To disable it, you have just uncheck the box as in the below screen:

Image title

In the Groovy Sandbox, the Administrator must approve the entire script in the in-process script approval page:

Image title

If you want to execute a currently unapproved method signature which will be halted by Jenkins, and administrator needs to approve the specific method signature before the script is allowed to execute.

For example:

Image title

There are three options: Approve, Deny, and "Approve assuming permissions check."

The first two know what we configured and accessed which we are approving and denying. The third requires some additional understanding of what internal data scripts are able to access and how permissions check inside of Jenkins function.

Learn how enterprises are using tools to automate security in their DevOps toolchain with these DevSecOps Reference Architectures.

Topics:
jenkins ,pipelines ,devops ,ci/cd ,tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}