Jenkins and GitHub are two very popular tools used by enterprise companies to build the CI/CD pipelines. The most common connection between these two is limited to what we expect from source management and build automation tools – they simply store our changes and prepare artifacts, sometimes also run deployments.  

To answer needs of our customer we had to become more creative and move to another level of integration of GitHub and Jenkins to automate process of verification of the changes recently added by Sitecore developers.  

The strategy we used can be very useful for Sitecore related projects but you can also find it valuable for other projects built in different technologies.  

 

The challenge 

We came up with the idea when the customer with a growing number of changes being added by multiple partners noticed that developers do not always verify if a solution can be built after the changes. On top of that, there was a need to verify if a solution could be built after the merge of the latest changes to the base branch – when branches with changes were not up to date.  

We did not want to run build on every push to the repository to all of the branches – it does not make sense as changes may not be ready to be verified.  

We did not want to run build on the environment related branches – it is too late as changes merged into these branches block the releases.  

We decided that the right time to start the test is when developers create pull requests. Creation of the PR usually means that you have set of changes that are ready to be merged and deployed after the review. The only issue is that Jenkins do not have an out-of-the-box mechanism that would allow to trigger build on the PR creation – so we had to use GitHub Webhooks to make it work.  

 

The process overview 

In this blog post we will not dive into the details of configuration. We want to focus on the process that we want to implement and details of the configuration will be covered in the separate blog posts in the future.  

Everything starts with the developer that opens GitHub and create the pull request where he tries to merge his branch to base branch of choice. It can be for instance feature branch being merged to master branch.  

When the PR is created GitHub server verifies if there is webhook configured for the particular action and sends data about the action to Jenkins. We are interested only in the actions related to pull requests (creation, update, … ).  

Jenkins receives information about the action related to the pull request and starts configured build to perform all planned steps.  

The Jenkins build consists of the following steps: 

• Extract information from the webhook 
• Gather more information through the GitHub API 
• Clone the repository 
• Checkout the head branch (branch of the developer) 
• Checkout the base branch (target branch) 
• Merge head branch into the base branch (locally) 
• Run msbuild and write results into the file 
• Verify if msbuild results contain any errors 
• Create comment in the PR via GitHub API 
• Inform creator of the PR about the change via email 

As you can see to setup that process we have to work on the configuration of: 

• GitHub 
  • Webhooks 
  • Authorization 
• Jenkins 
  • Pipeline and scripts 
  • Authorization 
  • Plugins 

Process itself is quite complex and information flows from one system to another but at the end when everything is connected we have a very powerful tools with capabilities limited mainly by our imagination.