How to make git feature branches work with jenkins-workflow?

Question

I'm trying to setup jenkins-workflow to do our integration tests. Our integration tests work like this:

Someone makes a change to LibraryA in a feature branch in git. We would like jenkins to run the unit tests against the code in the feature branch, then we would like to install the code from this feature branch into client1 and client2 (which are users of LibraryA ) and run their tests.

I was able to setup a workflow to do everything except get the right commit to the feature branch of LibraryA . Instead, my setup just pulls a commit from some (seemingly random) branch of LibraryA .

We have lots of feature branches, so hardcoding a particular branch in the workflow setup doesn't see appropriate. It seems like there should be some way to get the hash of the commit that triggers the workflow job (even when using SCM polling).

My setup looks like this:

currentBuild.setDisplayName("#" + env.BUILD_NUMBER)

node {
  git credentialsId: '033df7f1-7752-46bd-903d-8a70e613eed0', url: 'git@github.com:mycompany/myrepo.git'
  sh '''
echo `git rev-parse HEAD` > libraryA_version.txt
sudo docker run --rm=true -e LANG=en_US.UTF-8 -a stdout -i -t mycompany/libraryA run_tests
'''
  archive 'libraryA_version.txt'
}

def integration_jobs = [:]

integration_jobs[0]={
  node{
    ws {
      unarchive mapping: ['libraryA_version.txt':'.']
      sh 'sudo docker run -t --rm mycompany/client1:v1 bash run_tests.sh "`cat libraryA_version.txt`"'
    }
  }
}

integration_jobs[1] = {
  node{
    ws {
      unarchive mapping: ['libraryA_version.txt' : '.']
      sh 'sudo docker run -t --rm mycompany/client2 run_tests.sh "`cat libraryA_version.txt`" '
    }
  }
}

parallel integration_jobs

So, my current question is how can I setup the git repo/polling to get the right commit to run in the first test, which will be used in libraryA_version.txt in subsequent tests?

Alternatively, should I go about this process in a completely different way?

Answer 1

As @maybeg hinted, what you are most likely looking for is a multibranch project, available by installing Pipeline: Multibranch . That lets you define the script in a Jenkinsfile which simply calls checkout scm one or more times in your build, avoiding the need for libraryA_version.txt .

In the meantime, I am left wondering about your project setup. Your git step is using the default of branch: 'master' , meaning it should only be polling on the master branch to begin with, and only checking out this branch. The Git plugin is rather complicated, so perhaps this is broken somehow. Pending proper multibranch support, you could always use the checkout step with a GitSCM configured to use a wildcard branch spec, in which case an arbitrary branch head not previously built will be selected for checkout, and your git-rev-parse trick (I guess you independently rediscovered the workaround for JENKINS-26100 ) ought to work as is.

Answer 2

The feature you are looking for is Build-Per-Branch and in my view it should be implemented accordingly through fit-for-purpose plugins.

• Branching is done in git.

• Jenkins must copy the build or build pipeline job to fit the branch and being able to build and test the branch.

• After reintegration git must inform Jenkins and Jenkins must shut down the jobs.

I found this plugin:

https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin

And this plugin/tutorial:

http://entagen.github.io/jenkins-build-per-branch/

The implementation is strongly dependent on your scenario so i can't be more specific. I just say the challenges are:

• Building Jenkins jobs that can run concurrently and independently.

• Working with templates for Jenkins jobs.

• Handling events between Jenkins and git.

In your case:

• Build the whole process as a delivery pipeline from front to end.

• If someone branches a step and implements a feature then copy the whole pipeline and run the whole pipeline.

• Get this working then improve.