CENTOS v 6.4, GIT v 1.7.1 and JENKINS v 1.535 CONTINOUS INTEGRATION

Having tuned our Agile process to release iteratively and often I decided it was time to spend some time looking at how we could introduce continuous integration into our PHP and Javascript BDD workflows. Given that Travis isn’t suitable for most of our work (your code must be open source), I chose Jenkins as our CI server and was able to get up and running fairly quickly. I  found a few resources that covered integrating Git with Jenkins but I ended up doing a bit of digging myself so thought I’d quickly share the steps I followed.

Install Jenkins and Git

I provisioned a fresh CENTOS v 6.4 box, which meant I was able to follow the official Jenkins docs without any problems. If you’re using anything other than Ubuntu/Debian or Redhat you may need to look elsewhere. The installation instructions outline simple Apache or Nginx vhost configurations that can be used to serve the Jenkins administration console. You’ll need to install git on the same box so that Jenkins can eventually pull down, or commit to, your git repositories. To install Git I simply ran $ sudo apt-get install git (debian) and $ yum install git (Centos).

Install the Git Plugin

Once you can access your Jenkins console,  goto `Manage Jenkins -> Manage Plugins` from the home screen.
Open the ‘Available’ tab and find the plugin entitled Git Plugin.There is a filter box but it didn’t work particularly well for me, I ended up using Find in Chrome.

Create ssh key pair

Part of the installation process will create the user `jenkins` which will envoke all Jenkins processes, including all git commands. Therefore you’ll need to provision a keypair for this user then add the public key to your git repo. There’s a bit of trick to doing the former which I’ll cover now:

1. Login to your box and switch to the Jenkins user. The installation process doesn’t create a password so you’ll need to have root/sudo permissions to do this. Run the command sudo su - jenkins. The ‘-’ specifies a login shell, and will switch you to jenkins’ home directory (for me this was /var/lib/jenkins’).
2. Create a .ssh directory in the jenkins home directory.
3. Create the public private key pair. There are many tutorials which cover using the ssh-keygen command to do this. The most important thing is not to set a password, otherwise the jenkins user will not be able to connect to the git repo in an automated way.
4. Add the public key to your Git repo. We use bitbucket so this was fairly straightforward for me and I imagine anyone reading this will have performed similar actions for all their devs keys in the past.
5. Set a git user and email address. This is also mentioned in the git plugin documentation. Run:cd /srv/jenkins/jobs/project/workspacegit config user.email "some@email.com"git config user.name "jenkins".

Connect to the Git repo. This is a one time step which will dismiss that ‘Are you sure you want to connect’ ssh message, again jenkins won’t be able to deal with this. Just run ssh git@your_git_server_url info.

Create a new Job in Jenkins

The official docs provide a good level of detail on how to configure a basic Jenkins job, so I’d recommend following them here. The git-plugin docs also provide some useful info, so there’s not too much more for me to say other than list the steps I followed:

1. Select Git in Source Code Management.
2. Enter your git repository URL. This performs a asynchronous check and will give you an error if it can’t connect. Double check you followed the steps in #3 if you get an error.
3. Select the branch to build. This is branch jenkins will pull from when a build is started so enter whatever is suitable. We are building from develop so I entered this here.

Run a test Build

Once you’ve saved the job it’s worth kicking off a build to check everything’s working OK. You can do this in the main dashboard. Have a look at the latest build, you should see the commit id that was pulled down. If you dig around in the docs you’ll find that the plugin will have fetched your branch (in my case develop) and pulled from the remote repo. The repo is checked out into the job’s `workspace` directory and during the build the Jenkins user is cd’d into this directory. By adding your makefiles and build scripts into your repository it’s then a straightforward case of configuring the Jenkins job to execute these upon build. Again, this is covered in good detail in the docs.

Post Receive Hook

Finally you’ll need to setup your Git repository to initialise a build each time you push to your repository. Github and bitbucket both have hooks ready to be used, but if you’re self hosted a good place to start is at the plugin documentation which specifies the HTTP endpoint which can be used to trigger the job.

Sealing Packages within a JAR File

Packages within JAR files can be optionally sealed, which means that all classes defined in that package must be archived in the same JAR file. You might want to seal a package, for example, to ensure version consistency among the classes in your software.
You seal a package in a JAR file by adding the Sealed header in the manifest, which has the general form:

Name: myCompany/myPackage/
Sealed: true

The value myCompany/myPackage/ is the name of the package to seal.
Note that the package name must end with a "/".

An Example

We want to seal two packages firstPackage and secondPackage in the JAR file MyJar.jar.
We first create a text file named Manifest.txt with the following contents:

Name: myCompany/firstPackage/
Sealed: true

Name: myCompany/secondPackage/
Sealed: true

---

Warning: The text file must end with a new line or carriage return. The last line will not be parsed properly if it does not end with a new line or carriage return.

---

We then create a JAR file named MyJar.jar by entering the following command:

jar cmf MyJar.jar Manifest.txt MyPackage/*.class

This creates the JAR file with a manifest with the following contents:

Manifest-Version: 1.0
Created-By: 1.7.0_06 (Oracle Corporation)
Name: myCompany/firstPackage/
Sealed: true
Name: myCompany/secondPackage/
Sealed: true

Sealing JAR Files

If you want to guarantee that all classes in a package come from the same code source, use JAR sealing. A sealed JAR specifies that all packages defined by that JAR are sealed unless overridden on a per-package basis.
To seal a JAR file, use the Sealed manifest header with the value true. For example,

Sealed: true

specifies that all packages in this archive are sealed unless explicitly overridden for particular packages with the Sealed attribute in a manifest entry.