Pipeline JobsJENKINS PIPELINES

Jenkins Pipeline, or simply Pipeline, is a set of plugins that provide the functionality required to facilitate continuous delivery in Jenkins. This allows software to be taken from source code management (SCM) all the way to delivery, and allows the software to be maintained in a state in which it is ready to deploy.

There are several advantages to using Pipelines for your workflow:

• They allow you to express your jobs as code, and this means that they can be maintained alongside the code in SCM.

• Pipelines are durable and can survive Jenkins restarts, either planned or unplanned.• They can be paused to wait for input. This means that if processing requires direct approval it can be coded

into the Pipeline.• Pipelines can incorporate intelligent logic into job execution, which includes the use of conditionals and

loops.• They are extensible, allowing for custom extensions to the language in which they are written.

Pipeline JobsJENKINS PIPELINES

In the classic graphical user interface (GUI), Pipelines can be defined in the

Pipeline project type. This project type has an area in which the Pipeline code can be

entered directly.In this instance, the resulting Jenkinsfile is stored on the Jenkins master in the build's home directory. The classic GUI becomes

more difficult to use once the Pipeline becomes more complicated, or very large

with multiple stages and steps.

Blue Ocean Pipeline EditorJENKINS PIPELINES

The Blue Ocean editor is designed to give you a guided way to set up a Pipeline project. It ensures that you are connected to a Source Code Manager and then provides graphical steps that can be

used to create, update, and produce builds for your project. If you are not familiar with the structure of a Jenkinsfile, this is an excellent tool that can be used to learn more about the structure

of a Pipeline.

Scripted PipelinesJENKINS PIPELINES

Scripted Pipelines tend to follow an imperative model. This means that they

describe how something should be accomplished. They are based on a

programming language named Groovy. This provides a very versatile environment and

presents more flexibility and choice for when you want to have total control over the Pipeline. Scripted Pipelines are only

limited by the Groovy programming language. A Scripted Pipeline is a fully-

featured and extensible Groovy programming environment.

Declarative PipelinesJENKINS PIPELINES

A Declarative Pipeline is not as concerned with how we get a result, but what the result is. This means that the available

results are more limited. As such, Declarative Pipelines are less flexible but are

simpler to write. In a Declarative Pipeline, we do not create the small steps in the process. Instead, we indicate what the desired result will be. In a Declarative

Pipeline, we use the Pipeline DSL (Domain Specific Language), which specifies directives that the script executes.

Groovy and DSLJENKINS PIPELINES

Groovy is a fully-featured scripting language that is a subset of Java. It can be used inside the steps of the Pipeline, allowing you to make your Pipelines flow. And it adds functionality to the Pipeline that you would not otherwise have access to. Groovy and the Scripted Pipeline were

the original way that Pipeline in Jenkins was implemented. This created an issue in which there was a bit of a learning curve, and not all

Pipelines require Groovy.

Groovy can lead to more complicated Pipelines, and this was the reason for the Declarative Pipeline, which uses Domain Specific Language (DSL). DSL limits the choices that you have, and is very opinionated. This means that there is less to learn, and for simple Pipelines (that do not need error handling, for instance) DSL can be a better choice.

Jenkins File BasicsJENKINS PIPELINES

Jenkins files are used inside of source code repositories to provide the configuration for a job. A Jenkins file is read from top to bottom and

contains sections that indicate what configuration is contained in that section. A section is started with a keyword and then enclosed in

brackets.

Jenkins files and the configurations that they contain are intended to be versioned with the code that they build. Jenkins can be configured to ‘look’ for this configuration in the repositories and use it to create builds.

Pipeline TriggersJENKINS PIPELINES

A trigger is a process that causes a pipeline job to run. This is normally associated with a change in the code or a scheduled run of a build that

kicks off a pipeline.

SCM polling is when Jenkins is configured to check the Source Code Management solution on a schedule, and then run if the code has changed.

A WebHook is an event that is generated by a commit in a repository that then notifies Jenkins that there has been a change. This event triggers a run of the Pipeline job.

A build schedule configures Jenkins to build the job at a specific time, regardless of the state of the source code. This does not require an external event or a change in code to trigger the pipeline build.

Multibranch PipelineJENKINS PIPELINES

In a multibranch pipeline, Jenkins is given a URL for a Source Code Management repository. Once it has access to the repository, it scans all of the repository’s branches looking for Jenkinsfiles. For every branch that contains a Jenkinsfile, a job will be created. Upon initial creation, these jobs will run and the status of the job will be updated.

Production

Staging

Development

Production

Staging

Development

Global LibrariesJENKINS PIPELINES

A Global Library/Shared Library is shared groovy code that can be used inside of Pipelines.

Libraries that are configured at the top, or Global, level are considered trusted code and do not run in a sandbox. This code is available to all jobs on the system.

Libraries that are configured at the ‘folder’ level are non-trusted code and run inside of a groovy sandbox. These libraries are only available to the folder for which they are configured.

GLOBAL Job2

Job1

Job3

Folder1 Folder2

Library 1 Library 2

Job1 Job1 Job2Job2

If a Library is configured to “Load implicitly,” it is loaded automatically for every job that is in scope for the library (folder or global). If not, it must be loaded with the @Library() directive.

Variables and CredentialsJENKINS PIPELINES

Variables can be used in Pipelines. Variables have a scope, meaning that they are only valid in the block in which they are declared.

Variables that are declared at the top level are available to the entire pipeline.

pipeline{agent any

def globalvar = ‘global’stages{

Variables that are declared at the stage level are available only within that stage.

pipeline{agent anystages{

stage(‘local’){def localvar=‘local

steps{

Credentials are secrets that Jenkins will obfuscate so that they are not exposed in logs or Jenkinsfiles.

withCredentials([usernamePassword(credentialsId: ‘someID', passwordVariable: ‘upass', usernameVariable: ‘uname')]) {

echo “uname”echo “upass”

}

Started by userBuilding in workspace /home/Jenkins/workspace/example[example] $ /bin/sh –xe/tmp/hudson34559560912.sh+ echo **********+ echo **********Finished: SUCCESS

Docker in PipelinesJENKINS PIPELINES

Docker can be used in Pipelines as a build agent. This can be done to prevent software bloat on the build server. The dependencies are deployed in the container and then removed once the build completes.

A Docker container image can also be the product of a Pipeline. This allows Jenkins to be the deployment tool for Kubernetes, as well as production Docker Swarms.

Stage(‘build_image’){steps{

script{docker.build <registry> + <image_name>

}}

}

pipeline{agent{

docker { image ‘node:7-alpine’}}stages{

stage(‘build’){steps{

sh ‘npm run build…’}