Jenkis Pipeline with GitFlow

Git flow is one of branching strategies that has been commonly used lately. This strategy has 2 main branches; develop & master, and temporary branches like feature-*, release-*, or hotfix-* . You can understand more about this branching strategy here, https://nvie.com/posts/a-successful-git-branching-model .

To create a Jenkins Pipeline with this branching strategy, I ’m using a Generic Webhook Trigger which can receive a web hook from the apps repository and also filter the tag & branch name based on the naming pattern which you should have created before creating the Pipeline.

First you need to install the plugin first in your Jenkins https://yourjenkins.com/pluginManager/ . Then we could create a Jenkins Pipeline and enable it.

Next, we would make these 3 Jenkins Pipelines :

As there are lot of articles of Jenkins build trigger from Permanent Branch, I’m just going to share the staging & production Pipeline here.

So we are going to create the staging Pipeline first. Create a Jenkins Pipeline, and enable this build triggers.

Staging Pipeline

Then fill in the token section, in order for Jenkins to know which Jenkins Pipeline would run, I suggest you to configure it with the Jenkins Pipeline name so that it’s easily known which Pipeline the service repository would be built in.

Also enable JSON & Variables printing.

Next, we need to filter the update in the repository and I cannot just tell you the exact post content variables as it would different in each repository server depends on what server you’re using (bitbucket, github, gitlab etc). So we need to get the example of JSON that the repository would send it to.

Add a webhook in your repository with this https://yourjenkins.com/generic-webhook-trigger/invoke?token=pipeline-name

Make sure you have whitelisted the IP of your repository server if you ‘re implementing whitelist.

After it, then try to create a branch in the repository and the newly created Jenkins Pipeline would run and receive the full JSON from the repository.

Open the received JSON and take the JSON key where it has a value of the branch name. In my case , it would be

{
    "push": {
        "changes": [
        {
            "new": {
                "name": "release-0.0.14"
            }
        }]
    }
}

And would be converted to $.push.changes[0].new.name . And you can configure it in the post content parameters box.

Then we need to configure the filter so that only the changes that match with the release branch naming pattern would run the Pipeline.

^release.+[0–9]*\.+[0–9]*\.+[0–9]*$

I’m using this expression ^release.+[0–9]*\.+[0–9]*\.+[0–9]*$ which means the Pipeline would only run if only the value of $.push.changes[0].new.name is release- following by numbers, other than that the Pipeline would not run.

After that, we can add the clone code in the Jenkins Pipeline Code.

stages{
  stage('Clone'){
    steps {
      checkout([
        $class: 'GitSCM',
        branches: [[name:'*/release-*']],
        userRemoteConfigs: [[
          credentialsId: 'xxx',
          url: 'git@bitbucket.org:xxx/xxx'
        ]]
      ])
    }
  }
  stage('Build'){
    //
  }
  stage('Deploy'){
    //
  }
  stage('Automation Tests'){
    //
  }
}

Production Pipeline

For production pipeline, first follow the beginning step like the staging, create a pipeline, create token (same token),enable JSON & Variables printing, and test to create a tag so that you can get the json path of the tag name. In my case it’s same as when we create a branch $.push.changes[0].new.name and configure it in the post content parameters box.

And in the optional filter box we use the tagging pattern to filter the job to run the new tag only.

^[0–9]*\.+[0–9]*\.+[0–9]*$

stages{
  stage('Clone'){
    steps {
      checkout([
        $class: 'GitSCM',
        branches: [[name: 'tags/${TAG}']],
        userRemoteConfigs: [[
          credentialsId: 'xxx',
          url: 'git@bitbucket.org:xxx/xxx'
        ]]
      ])
    }
  }
stage('Build'){
    //
  }
  stage('Test'){
    //
  }
  stage('Deploy'){
    //
  }
}

So that is it. This is just one of many ways to follow the git flow, using Jenkins.