After linking Subversion (or Git) with JIRA, the build server looks like a worthwhile target too. Aim of the JIRA integration for Jenkins is to link JIRA issues with the resulting build artifact and to answer the question “Which build contains the bug fix for issue 1234?”. The Jenkins JIRA plugin therefore updates the JIRA issue by adding a comment containing a link to the generated build artifact.
The JIRA Plugin requires Jenkins, sadly it does not work with Hudson any more (this includes the latest Eclipse Hudson 3.0 milestone 2 release). It is possible to install the JIRA plugin in Hudson, even to configure it. However, including JIRA as post build action results into a java.lang.NoSuchMethodError: hudson.scm.ChangeLogSet$Entry.getCommitId()Ljava/lang/String; exception and a failed build.
Installation and initial configuration
Installation is simple: Open the Plugin Manager, install the JIRA Plugin and restart Jenkins:
The following initial configuration must be done only once on the Manage System page, in a corporate environment supposedly by a Jenkins administrator. Add a new JIRA configuration and provide the URL to your issue tracker, as well as username and the password. This user requires write access to all projects using the Jenkins JIRA integration. Since the username will show up as comment author, a service user like jenkins_ci or something similar makes it easier understandable where those comments are coming from. Finally, check the Record Scm changes checkbox and save your changes.
In case a certificate exception like sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target shows up at the URL textfield, Jenkins doesn’t find or recognize the JIRA server certificate (especially if it is a self-generated one). Simply obtain this certificate and import it using the Java keytool (replace [jira-domain] with your domain name):
keytool -import -alias [jira-domain] -keystore $JAVA_HOME/jre/lib/security/cacerts -file file.cer
The JDK (or JRE) entered for the keystore must be the one configured for Tomcat. You have to use this keystore (Linux requires usage of the sudo command)! Password of the global cacerts keystore should be changeit. Jenkins (Tomcat) needs to be restarted after the import. In case the exception is still there, either the imported certificate was not the correct one, the alias is not correct or the given Java path is not the Java installation used by Tomcat.
Individual project configuration
Now every project can use the JIRA integration. First of all, create your JIRA project and your SVN (or Git) repository as usual. Then start a new Jenkins build or modify an existing one. Set up all required build steps as usual.
Each project must enable the JIRA Jenkins connection individually. This requires write access for the Jenkins service user to your JIRA project. This user will update the corresponding issues with a comment after a build.
After this initial organizational task and the basic project setup, the projects Post-build Actions in its build configuration must be updated by selecting Update relevant JIRA issues. No additional JIRA configuration is required here. But it may make sense to periodically poll the SCM by configuring a schedule (like every couple of minutes). Otherwise you’ll have to start the build manually.
Day to day project usage
There are no special tasks or steps required to take advantage of the Jenkins JIRA integration. The only requirement is, that a SVN/Git commit contains the JIRA issue ID in the commit message (e.g. as it is done automatically by Eclipse Mylyn with an active task). Every new commit included in a new build will be searched for JIRA issue IDs. Each issue will contain the same comment created by the Jenkins JIRA plugin pointing to the generated artifact.