Dragon Slayer Supplement: Action Issues with Commit Commands

Automated performance testing using JMeter and Maven »

Dragon Slayer Supplement: Action Issues with Commit Commands

James Roper talks about JIRA October 8, 2009 11:57 PM

So, you've slayed the Atlassian integration dragon. But you're still edgy, it was too easy! You want something harder. Well I have just the task for you. Actioning JIRA issues from Subversion commit messages. Before I go on, let me say, this task is not part of the official Atlassian Dragon Quest. You will not get another free tshirt if you complete this task. But, you will get one cool integration feature from Atlassian's products.

Actioning issues from commit messages is a feature that has been available in JIRA Studio for around a year. The documentation on how to use it (once it's set up) can be found here. This feature was, from the start, written as a feature that could be used outside JIRA Studio. However, there was a small amount of effort required to get it to that point. That effort has never been done, until now. Well, some of it has been done. It's still only recommended to be tried by only the bravest of dragon slayers.

First, a bit about how actioning issues with commit commands work. Atlassian has a little known cross product plugin called the Atlassian Notifier. This plugin implements WebHooks for Atlassian products. Using a REST interface, other servers can subscribe to notifications of events on the Atlassian product. In our case, a servlet in the JIRA FishEye plugin will subscribe to commit notifications from FishEye, this servlet will parse the commit messages, and action JIRA issues accordingly.

Requirements

In order to complete this task, you will need:

To have completed the Atlassian Dragon Quest
Version 3.1-beta2 of the JIRA FishEye plugin, available here
A patch for the built in JIRA workflow
The FishEye Atlassian Notifier plugin version 2.1-beta1, available here
A Subversion repository that you can commit to (can be a local filesystem repository)
The Firefox Poster plugin

Setup

Install the JIRA FishEye plugin 3.1-beta1 into the plugins/installed-plugins directory in the JIRA home directory
From the atlassian-jira directory, apply the workflow patch, using the command patch -p0 < jira-workflow.xml.patch
Restart JIRA
Install the FishEye Atlassian Notifier Plugin into the var/plugins/user directory in FishEye
Restart FishEye
Add your Subversion repository to FishEye.
Grant the "charlie" user you created administrator access to FishEye. This can be done by clicking the Administrators link in the FishEye administration menu.
In Firefox, log in to FishEye with the charlie user. Now, using the Firefox Poster plugin, send a POST request to {your fisheye base url}/plugins/servlet/notifier/{your repository}/COMMIT, with content type application/x-www-form-urlencoded, and the content url={your jira base url}/plugins/servlet/commitnotification&authenticationType=TRUSTED_APPS&username=charlie. The response code should be 201 Created.

You're now ready to go.

Testing

Create an issue in JIRA
Check out your source code. If using a file system SVN repository, make sure you specify the --username charlie option.
Make a change, and then commit, with a commit message of {ISSUEKEY} #resolve It works

Within a couple of minutes, your issue should be resolved, and a comment "It works" added to the issue.

If these instructions don't work for you (remember, this task was not for the faint hearted!), then please leave your feedback as comments on this post.

Tweet this •

Tags: fisheye jira commit action issues

5 Comment(s)

Nice! A few questions.

1. Step 8, what's that for? Enabling something in FishEye it looks like.

2. What about custom workflows, how to add their details? Is the #resolve based on the transition name in JIRA (case-insensitive) or something else?

And in general, how does this handle rebuilding a FishEye index? Does FishEye resend all the notifications so that JIRA will suddenly have a frenzy of trying to action issues that have already been actioned.

~Matt

By Matt Doar at October 9, 2009 11:40 AM

1. Step 8 is setting up the subscription from FishEye to JIRA of commits. It tells FishEye, everytime there's a commit, to post the details to JIRA at that URL. This functionality is provided by the Atlassian Notifer plugin, and can be used as a generic webhook to post commits to anything. The authenticationType can also be BASIC, in which case it will use HTTP BASIC authentication, and you need to supply a password parameter as well. You can also specify NONE for authentication.

2. There is an administration screen for configuring commit commands: http://confluence.atlassian.com/display/JIRASTUDIO/Configuring+Commit+Commands+for+Issues The instructions there apply to the JIRA Studio administration layout, but the commit commands link can be found in the Global Settings section of the administration menu. The commands are actually stored as properties on the workflow, this is why the patch is needed, because JIRA doesn't allow editing the built in workflow.

I'll have to check, but I don't think rebuilding the index will cause notifications to be resent. The worst it will do is cause notifications to be missed. The commit event publishing mechanism stores the ID of the last revision it published in the index itself, and only publishes revisions since that index. If the it doesn't find that stored ID, which would happen when you first point FishEye at a repository or if you rebuild the index, it doesn't publish anything, it just stores, and this only happens after the entire index has finished rebuilding. So, when you rebuild the index, any commits that happen while its being rebuilt may not be published. There is still a chance of JIRA being hammered, if FishEye goes down for a long time, and then is brought back up, and lots of commits have happened in the mean time.

If you do try this, would appreciate any feedback you have. It is likely that at some point we'll add subscribing to commit notifications a button on the administration screen for the JIRA FishEye plugin. Getting this to a state usable outside of JIRA Studio was just something that I decided to do last Friday as part of my 20% time, because I thought it was about time we offered it to customers (many have asked about it).

By James Roper at October 10, 2009 5:23 AM

Thank you very much for the solution.

We still had to add the two paths
   /plugins/servlet/streams
   /plugins/servlet/commitnotification
to the
   URL Paths to Allow:
list in the FishEye trusted application configuration in JIRA

By Andreas Würl at October 12, 2009 4:23 AM

Thanks for the walk through. I've got both beta plugins installed and the POST returned a 201, but I can't download the xml.patch file because the SVN repo is requesting a username and password.

So I'm stuck with a blank "Commit Notification Command Mappings" page in JIRA Administration.

Interestingly enough, the page lists the table header (Command|Transitions|Action) and an 'Add workflow command mapping' link.

A workaround others might be interested in. I've copied the default jira workflow, created a new workflow scheme, and assigned a workflow to each issue type of the new workflow scheme. Finally, for each project, I needed to change the workflow scheme from None to Copied Workflow.

By Brad at December 8, 2009 1:46 PM

Hi Brad,

The commit notification command mappings page I think had a bug in it (overlooked by me in my race to get something done on a Friday afternoon). This has since been fixed and beta 2 has been released:

http://maven.atlassian.com/contrib/com/atlassian/jira/plugins/jira-fisheye-plugin/3.1-beta2/jira-fisheye-plugin-3.1-beta2.jar

Let me know if this fixes it.

That SVN repository has recently been made private, I've copied the patch to this website:

http://blogs.atlassian.com/developer/commitnotifications/jira-workflow.xml.patch

I hope this works for you!

By James Roper at December 8, 2009 3:57 PM