About Juri Strumpflohner

Juri Strumpflohner mainly operates in the web sector developing rich applications with HTML5 and JavaScript. Beside having a Java background and developing Android applications he currently works as a software architect in the e-government sector.

Git flow with Jenkins and GitLab

At work I recently transitioned from TFS to using Git as our source control management. After introducing the team to Git we also established a common workflow on how we wanted to have Git integrate with Jenkins and GitLab. Below is our current implementation.

Git branching strategies

Git branching strategies are guidelines on how to use git’s branching mechanism for your development. Establishing such a shared convention is especially useful for having a common vision in the team, in order to have everyone steer in the right direction.

There are a couple of git branching strategies around which I’d not like to go into the very details right now. The interested among you might want to consider some of these links

Making git-flow work on Jenkins and GitLab

At work, one of our teams recently switched from TFS to Git where we decided to adopt a “git-flow” similar style of working, having

  • master being the main development branch,
  • production being the one containing the production releases,
  • story/<storyname> being feature branches per userstory
  • …and some other support branches for preparing releases, hotfixes etc.

These branches get published onto our internal Git server powered by GitLab. What we obviously wanted as well is to integrate this strategy with our Jenkins build server, having

  • each checkin on master being automatically deployed in a staging/dev environment
  • each checkin to a story/ branch to be build and verified against the .Net and JavaScript unit tests (and in the future integration tests as well, hopefully)
  • each checkin to production/ to be build, tested and automatically deployed in a “production-like” environment which is currently only visible to the client, but in the future intended to be accessed by all users

Jenkins jobs

Based on the above assumptions we currently create one Jenkins job per environment, one for master, one for the user story branches and one for production (although I have the feeling Jenkin’s build parameterization could help out here to avoid redundancy between the build configurations…but didn’t look into that, yet). Let’s take a look at the master configuration as the others can be easily deduced starting from that one.

1. Source Code Management – Git Configuration

Before starting, make sure you have the Jenkins Git plugin. Then create a new Jenkins job, and in the “Source Code Management” section configure your Git repository like in the img example below.

Git configuration

Git configuration

In the Branch Specifier field, enter your desired branch, depending on which one you’re going to build in this current job. For master simply enter */master, for building your feature/userstory branches (and given you start them with story/<name>), enter */story/* and so on.

2. GitLab Webhook

The next step is to add a web hook to GitLab. This is needed s.t. GitLab is able to signal to Jenkins about new commits that have been “pushed” to the repository. This is an alternative, but much more efficient way of instead doing a continuous polling.

Just go to your repository settings and then to Web Hooks.

Gitlab hook for communicating with Jenkins

Gitlab hook for communicating with Jenkins

Enter an url of the form http://myjenkins.com/git/notifyCommit?url=git@mygitlabserver.com:myrepo.git.

3. Set polling

The final step is to setup polling. Hä? Sorry, didn’t you just mention previously that we don’t need polling ’cause GitLab calls Jenkins in case of new commits?? Yep, that’s right, but that’s part of a “security” measure the guys creating the Git plugin introduced to make sure you (that you control the Jenkins job) and you (that you added the Web Hook) both consent to execute the build based on new commits.

This will scan all the jobs that’s configured to check out the specified URL, the optional branches, and if they are also configured with polling, it’ll immediately trigger the polling (and if that finds a change worth a build, a build will be triggered in turn.) We require the polling configuration on the job so that we only trigger jobs that are supposed to be kicked from changes in the source tree. Source

However, in the polling configuration you don’t have to specify any kind of interval, meaning that it won’t start by its own. You simply tick the checkbox “Poll SCM” to give your consent (somehow).

Git polling configuration

Git polling configuration

That’s it, now your Jenkins jobs should start based on the branch you configured in your job and based on the branch that gets pushed to GitLab, just as we wanted.

Alternative approaches

In case you just need to trigger the build of a branch from GitLab, you can also simply configure Jenkin’s remote trigger and add that as a Web Hook to your GitLab repo

Remote trigger configuration

Remote trigger configuration

The downside of this approach is that you’re not able to selectively launch builds based on commits on certain branches.

Finally, I also found a plugin called GitLab Hook which I didn’t try yet as the above described approach was much simpler (and didn’t require the installation of a plugin). On their page they write that

For GitLab [...] For Gitlab there is an existing solution that might work for you. You can just use the notifyCommit hook on Git plugin like this. [...] But, with a large number of projects that are mostly polling (no hooks), the project might actually be built with a great delay (5 to 20 minutes). You can find more details about notifyCommit and this issue here. GitLab Hook plugin page

I did not experience any of such delays so far, but we’ll see.
 

Reference: Git flow with Jenkins and GitLab from our JCG partner Juri Strumpflohner at the Juri Strumpflohner’s TechBlog blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


two × = 4



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close