Jenkins Basics

Jenkins.md

What is Jenkins?

Jenkins is a self-contained automation server that allows continuous integration and continuous delivery of projects, regardless of the platform you are working on. It is a free source that can handle any kind of build or continuous integration. You can integrate Jenkins with a number of testing and deployment technologies.

Why Jenkins?

Jenkins is a software that allows continuous integration. Jenkins will be installed on a server where the central build will take place. The following flowchart demonstrates a very simple workflow of how Jenkins works.

Installing Jenkins:

1. Go to: https://jenkins.io/

2. Click on Download.

3. Select Jenkins for your suitable Operating System.

4. Jenkins will start downloading.

5. Extract the ZIP file and start the installer.

6. Follow the instructions to complete Jenkins installation.

7. After the installation is complete, the installer launches the browser which opens localhost:8080. localhost:8080 is the default port in which the Jenkins runs on.

8. Copy the initial Administrator password from the given location and paste it to the input box.

9. Click on continue.

10. Jenkins suggests us to install plugins.

11. Click start using Jenkins.

Jenkins Terminologies:

1. Job/Project:

These two terms are used interchangeably. They refer to runnable tasks that are controlled/monitored by Jenkins.

####2. Slave/Node:

Slaves are computers that are set up to build projects for a master. Jenkins runs a separate program called “Slave agent” on slaves. When slaves are registered to a master, a master starts distributing loads to slaves. Node is used to refer to all machines that are part of Jenkins grid, slaves and master.

3. Executor:

Executor is a separate stream of builds to be run on a node in parallel. A node can have one or more executors.

4. Build:

A build is a result of one of the projects.

5. Plugin:

A plugin is a piece of software that extends the core functionality of the core Jenkins server.

Jenkins’ Master and Slave Architecture:

Jenkins uses a master and slave architecture to manage distributed builds.

Jobs done by master:

1. Schedule build jobs.

2. Dispatch builds to the slaves for the actual job execution.

3. Monitor the slaves and record the build results.

4. Execute build jobs directly.

Job done by Slave:

1. Execute build jobs dispatched by the master.

It is possible to configure a job to always run on a particular slave machine or a particular type of slave machine

Setting up Git for Jenkins:

1. Click on ‘Manage Jenkins’ option on the left-hand side menu.

2. In the next screen, click on ‘Manage plugin’ option.

3. In the next screen, click on the ‘Available’ tab. (This tab will give a list of plugins which are available for downloading.

4. In the ‘Filter’ tab type ‘Git Plugin’.

5. Check the ‘Git Plugin’ option and click on ‘Install without restart’.

6. The plugin will then be installed.

Setting up Maven for Jenkins:

1. From the Jenkins dashboard, click on ‘Manage Jenkins’ from the left-hand side menu.

2. Click on ‘Configure System’ from the right-hand side menu.

3. In the ‘Configure System’ screen, scroll down to the ‘Maven’ section and click on ‘add Maven’.

4. Uncheck ‘Install automatically’ option.

5. Add any name for the settings.

6. Add location of the MAVEN_HOME.

7. Click on save.

Jenkins Management:

From the Jenkins dashboard, click on ‘Manage Jenkins’. Now we can get various configuration options to manage Jenkins.

The management options are:

1. Configure System:

This is where one can manage paths to the various tools to use in builds, such as the JDKs, the versions of Ant and Maven, as well as security options, email servers, and other system-wide configuration details. When plugins are installed. Jenkins will add the required configuration fields dynamically after the plugins are installed.

2. Configure Global Security:

This where we can configure the security of Jenkins. We can define who is allowed to access or use the system.

3. Configure Credentials:

This is where we can configure the credential providers and types.

4. Global Tool Configuration:

This is where we can configure tools, their locations and automatic installers.

5. Reload Configuration From disk:

Jenkins stores all its system and build job configuration details as XML files which is stored in the Jenkins home directory. Here also all of the build history is stored. Migrating build jobs from one Jenkins instance to another, or archiving old build jobs, we will need to add or remove the corresponding build job directories to Jenkins’s builds directory. We don’t need to take Jenkins offline to do this—we can simply use the “Reload Configuration from Disk” option to reload the Jenkins system and build job configurations directly.

6. Manage Plugin:

Plugins can be installed, updated and removed through the Manage Plugins screen.

7. System Information:

This screen displays a list of all the current Java system properties and system environment variables. Here one can check exactly what version of Java Jenkins is running in, what user it is running under, and so forth. We can also see the plugins and thread dumps.

8. System Log:

The System Log screen is a convenient way to view the Jenkins log files in real time. The main use of this screen is for troubleshooting.

9. Load Statistics:

This page displays graphical data on how busy the Jenkins instance is in terms of the number of concurrent builds and the length of the build queue which gives an idea of how long the builds need to wait before being executed. These statistics can give a good idea of whether extra capacity or extra build nodes is required from an infrastructure perspective.

10. Script Console:

This screen lets you run Groovy scripts on the server. It is useful for advanced troubleshooting since it requires a strong knowledge of the internal Jenkins architecture.

11. Manage Nodes:

Jenkins is capable of handling parallel and distributed builds. In this screen, we can configure how many builds we want. Jenkins runs simultaneously, and, if we are using distributed builds, set up build nodes. A build node is another machine that Jenkins can use to execute its builds.

12. Manage Old Data:

Scrub configuration files to remove remnants from old plugins and earlier versions.

13. Manage Users:

We can create, delete and modify users that can log into Jenkins.

14. Prepare for shutdown:

If there is a need to shut down Jenkins, or the server Jenkins is running on, it is best not to do so when a build is being executed. To shut down Jenkins cleanly, you can use the Prepare for Shutdown link, which prevents any new builds from being started. Eventually, when all of the current builds have finished, one will be able to shut down Jenkins cleanly.

Creating a Jenkins job

1. Go to the Jenkins Dashboard.

2. Click on ‘New Item’.

3. Enter an Item Name (Job name).

4. Select the type of project.

5. Click on OK.

(Next steps are for freestyle project.)

6. Enter the Project Description.

7. Select how and where the build job will be executed below the ‘Description’ tab (not necessary).

8. Select the Source Code Management (e.g. Git, Subversion).

9. Specify the Build Triggers (not necessary).

10. In the ‘Build’ section define the actual Build steps.

11. Click on ‘Add build step’ and add the steps.

12. We can add post-build action in the ‘Add post-build action’ tab (not necessary).

13. Click on save.

14. Jenkins job will be created and we can see the job in the dashboard.

Running a Jenkins Job:

1. Go the dashboard.

2. Click on the build now button on the last column of the project entry.

3. Click on the job name to enter the main page of the project.

4. We can see the build being scheduled.

5. We can see the state of build under the Build History on the left-hand side menu.

In Jenkins the blue ball indicates success and a red ball indicates failure.

6. If we click on the ball, it will take us to the main page of the build.

7. Click on ‘Console Output’ on the left-hand side to view the console output of the job.

If we go to the dashboard now we can see the status of the job represented in terms of blue or red ball (Blue ball meaning success and red ball meaning failure). This is the shown in the first column.

The second column is the weather. This shows an aggregated result of all the recent builds. Sunshine means that all the recent builds are successful.

We can also see the Last success and last failure and the duration of the latest build.

Creating a Maven based job using Git as Source Code Management Tool:

1. Click on New Item.

2. Enter an Item name.

3. Click on Freestyle project.

4. Click on OK.

5. Give the description.

6. Select Source Code Management as Git.

7. Supply the Repository URL for Git.

8. Select the branches to build.

9. Add Build Step: Invoke top-level Maven targets.

10. Select Maven version as local Maven.

11. Select the Goals.

12. Click on Save.

Running the Maven job:

1. Click on the Maven Project created from the dashboard.

2. Select Build Now from the Left-hand side.

3. The build will then be triggered.

4. Click on the Build number of the Maven project from the left-hand side.

5. Now clicking on the Console Output from the left-hand side, Jenkins will view the console output of the Build.

We can go to the Workspace of the project to view our project.

Source Control Polling in Jenkins:

Using the Source Control Polling we can use Jenkins to trigger a build periodically.

1. Select the project created.

2. Select Configure from the left-hand side panel.

3. Scroll down to the Build Triggers section and select Poll SCM option.

4. Then in Schedule field we can enter how often we want to trigger a build. The schedule field follows the cron format.

Cron format:

Cron format consists of five fields separated by white spaces:

      <Minute> <Hour> <Day_of_the_Month> <Month_of_the_Year> <Day_of_the_Week>

The following graph shows what it consists of:

            * * * * * 
            | | | | |  
            | | | | | 
            | | | | +---- Day of the Week   (range: 1-7, 1 standing for Monday)
            | | | +------ Month of the Year (range: 1-12)
            | | +-------- Day of the Month  (range: 1-31)
            | +---------- Hour              (range: 0-23)
            +------------ Minute            (range: 0-59)

Any of these 6 fields may be an asterisk (*). This would mean the entire range of possible values, i.e. each minute, each hour, etc.

Any field may contain a list of values separated by commas, (e.g. 1,3,7) or a range of values (two integers separated by a hyphen, e.g. 1-5).

After an asterisk () or a range of values, you can use character / to specify that values are repeated over and over with a certain interval between them. For example, you can write "0-23/2" in Hour field to specify that some action should be performed every two hours (it will have the same effect as "0,2,4,6,8,10,12,14,16,18,20,22"); value "/4" in Minute field means that the action should be performed every 4 minutes, "1-30/3"means the same as "1,4,7,10,13,16,19,22,25,28".

In Month and Day of Week fields, you can use names of months or days of weeks abbreviated to first three letters ("Jan, Feb,…,Dec" or "Mon,Tue,...,Sun") instead of their numeric values.

5. We want to build trigger as frequently as possible. So, we use * * * * * in the schedule field. This will trigger a build every minute.

6. Click on Save.

7. Go to the project and a new item is added to the left-hand side panel which is “Git Polling Log”.

8. Click on the Git Polling Log from the left-hand side panel.

9. Now Jenkins will trigger a Build every minute and view the changes in the Git Polling Log.

Other Build Triggers of Jenkins:

1. Trigger builds remotely (e.g., from scripts):

Jenkins provides machine consumable remote access APIs to its functionalities.

i) Supply the token name in Authentication Token field.

ii) Copy the URL given below. (The URL is used to trigger a build.)

iii) Save the configuration.

iv) Open a new tab in the web browser.

v) Paste the URL in the address bar.

vi) Replace JENKINS_URL with localhost:8080 and TOKEN_NAME with the token name given.

vii) Press Enter to fire the request.

viii) Jenkins page will then view that a build has been triggered.

This remote execution function is very handy. We can use it to trigger a Jenkins build either from a script or from other application.

2. Build after other projects are build:

This option will let us set up a build that will be run whenever another build is finished. We just need to add the preceding build job in the Projects to watch field. We can add multiple projects to watch separated by commas.

3. Build periodically:

We can use the Build periodically option to create scheduled builds. In the schedule field we can enter how often we want to trigger a build or when to trigger a build. The schedule field follows the cron format.

4. Build when a change is pushed to GitHub:

This feature enables builds to be triggered when a change is pushed to the GitHub repository. Basically, instead of Jenkins pulls SCM periodically what happens here is whenever a commit is made to GitHub a web hook will be triggered which will notify Jenkins to trigger a build right away. In order to enable this build trigger, we need to set up the hook between Jenkins and GitHub. We have to use the GitHub plugin to setup the hook between GitHub and Jenkins.

Deploying Artifact to staging Environment:

We need to archive the artifact which is generated from a project and then in the next job we will pick up the artifact and deploy it to the staging environment.

Archiving artifact of a project:

1. Go to the configuration page of the project.

2. Scroll down to the post build action section.

3. Click “Add post-build action”.

4. Select “Archive the artifacts”.

5. Enter files to archive in the “Files to archive” tab.

6. Click on save.

7. Now triggering a build will archive the artifact.

Creating Job to deploy artifact to staging environment:

1. Install “copy artifact” plugin and “deploy to container” plugin.

2. Go to dashboard and select New Item.

3. Enter the Job name.

4. Select Freestyle project.

5. Click on OK.

6. Scroll down to the Build section.

7. Click on Add build step.

8. Choose copy artifact from another project.

9. Enter the project name to copy artifact from.

10. Enter the artifacts to copy.

11. In the Post-Build Actions select Deploy war/ear to a container.

12. Enter WAR/EAR files.

13. Select the container.

14. Fill in the Container credentials and URL.

15. Click on Save.

Now the job we created (downstream job) will take the artifacts created from upstream job and deploy it to the staging environment. The upstream job is the project which archives the artifacts. This downstream job should be automatically triggered if the upstream job completes successfully. We can achieve this by adding a post-build action to the upstream job.

1. Go to the configuration page of the upstream job.

2. Scroll down to the post-build action section.

3. Select Add post-build action and choose Build other projects.

4. Enter the name of the job which is the downstream job.

5. Click on Save.

Now if we trigger the build of the upstream job then the artifact will be deployed to the staging environment.

Jenkins Build Pipeline:

The Jenkins Build Pipeline gives the ability to form a chain of jobs based on their upstream\downstream dependencies. Downstream jobs may, as per the default behaviors, be triggered automatically, or by a suitable authorized user manually triggering it. We can view the Jenkins Build pipeline by installing “Build Pipeline” plugin.

1. Go to Jenkins dashboard.

2. Click on the “+” sign beside the “ALL” tab to create a new view.

3. Enter a view name and select “Build Pipeline View”.

4. Click on OK.

5. Select the initial job which marks the starting point of the build pipeline.

6. Click on OK.

7. Now we can see the Build Pipeline View.

8. We can start the jobs in the pipeline by clicking on the run button.