Setting up Continuous Integration on Jenkins

New challenges are the toughest especially when it is completely out of your comfort zone. I have been working on setting up UI workflow and pipeline lately which was something I had never done before. While working on the pipeline I did not find any self-sufficient resource to guide me setup continuous integration on Jenkins(I had my reasons why I had to choose Jenkins). Through this blog, I want to share my experience of setting up the CI pipeline on Jenkins so that it helps others.

What is Continuous Integration?

Continuous integration is the software development practice where multiple members of the team integrate their code in a shared repository continuously.

This can lead to errors or conflicting scenarios as multiple people are contributing to the same code base. It is important to find these integration errors as early as possible to ship a stable product to the customers. This is usually achieved by running sanity checks, test cases, etc. It is out of the scope to run these manually and are usually verified by an automated build.

In my case, I was pushing my code to GitHub and had to run these automated checks on Jenkins when any Pull Request is opened so we don’t run into any unwanted scenarios during code integration.

CI workflow(in my case)

• The GitHub needs to send an event to Jenkins when a Pull Request is opened.
• Jenkins job should listen to the incoming event from the GitHub and start the automated checks.
• Jenkins needs to communicate back the status of the automated checks to the GitHub.

Let’s discuss each of the building blocks in detail.

The GitHub needs to send an event to Jenkins when a Pull Request is opened.

GitHub has a feature called webhooks that allow you to build or set up integrations and subscribe to certain events on GitHub.com. When an event is triggered, GitHub sends an HTTP POST payload to the webhook’s configured URL. To set up a webhook you need to go to your repository settings and select webhooks option. You have to provide the payload URL( make sure it is public IP) and select events you are interested in.

You are all set and good to go from the GitHub side.

Jenkins job should listen to the incoming event from the GitHub and start the automated checks

On the Jenkins side, you have to add the GitHub integration plugin if you want to listen to any incoming push events. In my case, I only wanted to act when a Pull Request is opened so I added the GitHub Pull Request Builder plugin. Make sure you add global credentials(user should have the right permissions to the repository) to the Builder plugin else the job won’t be able to listen to the incoming events.

Additionally, you would have to add Refpspec(tells git how to map references from a remote to the local repo) and Branch specifier(tells which branches should be built).

You are all set to listen to the incoming Pull Request event coming from Github.

Jenkins needs to communicate back the status of the automated checks to the GitHub

Time to install one more plugin on Jenkins, add Hudson Post Build Task Plugin to send back the build status to GitHub. You have to add two tasks as the post-build step that calls the GitHub API in success and failure scenarios.

Now that both Jenkins and GitHub are configured, the check status will be shown on GitHub against the Pull Request.

You have set up your CI pipeline to perform automated checks when any Pull Request is opened.

If you liked reading this, don’t forget to clap. 👏👏

You can also follow me on twitter @Akash940 for JavaScript or React updates.

Thank-you!