Things are moving along on branch support and Jira 4.0 support
|
| Name | Jira Git Plugin |
|---|---|
| Version | 0.4 |
| Product Versions | 3.12, 3.13 |
| Author(s) | J. Longman |
| Homepage | http://confluence.atlassian.com/display/JIRAEXT/Jira+Git+Plugin |
| Price | Free! |
| License | BSD with some EPL |
| JavaDocs | |
| IssueTracking | JGIT Jira Developer Site |
| Download JAR | jira_git_plugin-0.4.jar |
| Download Source | http://svn.atlassian.com/svn/public/contrib/jira/jira_git_plugin/ |
Description/Features
Git integration into Jira, ala the Subversion plugin. Uses jgit and the original subversion jira plugin. Web integration is supported for gitweb.
| Currently only monitors one branch now - I am looking to fix this for the 0.5 release One workaround is to add new repositories to monitor other branches. |

This plugin has been updated to Java 5
Installation
| This page has been deprecated in favour of Managing JIRA's Plugins. |
Installing plugins in JIRA is easy.
Once you have downloaded or created your plugin jar, follow these steps:
- Shut down JIRA
- copy '$MY_COOL_PLUGIN.jar' into '.../atlassian-jira/WEB-INF/lib/'
- Start up JIRA.
- Go to 'Administration > Plugins' and confirm that $MY_COOL_PLUGIN is listed and enabled.
- Enjoy!
Usage
- git clone the source tree you need on your jira machine (probably as the same user jira runs as, TBD)
- in Jira:
- Go to the git Repositories panel in the Administration section
- Add a new repository
- Name it
- Put the path from Step 1 in the Repository root path
- Put the url to the git repository in the next part (note to self, can this be removed?)
- Choose gitweb as a web tool, you may need to customize the URLs
Examples
Version History
| These versions are SNAPSHOT since the jgit library had not, as of the time of my releases, released a non-SNAPSHOT version. Maven thus prevented me from doing a release. |
| Release | Jira Version | Notes |
|---|---|---|
| 0.4 | 3.13 | 18/Aug/2009. Patches from Jeppe Toustrup |
| 0.3 alpha - 1/Mar/09 | 3.13 | First 3.13 Alpha |
| 0.2 | 3.12 | Second Release |
| 0.1 - 29/Oct/08 | 3.12 | Splash Landing |
| Experimental | JIRA Version | notes |
|---|---|---|
| branch support | < 4.0 | partial, based on 0.3-SNAPSHOT |
| 4.0 support | 4.0 | see notes when you clickthru |
0.4 Release Notes
- upgrade to jgit 0.5.0 so we can do a non-snapshot release
- abbreviate SHA1 id to 7 characters (JT)
- fix git directory issue (JT)
- attempt to show most recent issues in project git panel (my test set wasn't large enough to verify)
- fix random characters in git project panel (JT)
Not fixed is tracking multiple branches. The current workaround is to have a repository per branch.
Open Issues
jiraissues: Unable to determine if sort should be enabled.
Building the code
jgit and maven
jgit has released 0.5.0 as a non-snapshot release which permits me to non-snapshot release. Huzzah!

Comments (34)
Feb 09, 2009
Mick Barry says:
I can't get this to work, keep getting an error about the repo root I specify. ...I can't get this to work, keep getting an error about the repo root I specify.
Am using 0.1
# Connection to git repository file:///var/spool/git/ssv failed: gitdir is null
/var/spool/git/ssv is the directory that contains the .git directory
Mar 06, 2009
J. Longman says:
Please try the latest build. Incidentally, working with the project is very eas...Please try the latest build.
Incidentally, working with the project is very easy thanks to Atlassian's PDK. Checkout the code from svn, get java and maven (m2) and then the environment is self-hosting:
and you've got a jira running on your machine with a developer license and the plugin with your code at http://localhost:1990/jira.
very cool.
Aug 18
J. Longman says:
If you were still having problems, try version 0.4. Also, I've removed the svn-...If you were still having problems, try version 0.4. Also, I've removed the svn-style text and I used a non-file:// or file:/// prefix and it worked (on OSX).
Apr 10, 2009
Trevor Robinson says:
The instructions for using this plug-in say to 'git clone' the repository. Will ...The instructions for using this plug-in say to 'git clone' the repository. Will the plug-in periodically 'git pull' to update the cloned repository, or will it just become outdated? I'm wondering if I should instead try to run directly off the "central" repository URL (i.e. the one our developers clone from). Thanks for any guidance!
Jun 10, 2009
Ken Miller says:
Very happy to see this plugin. We've got it hooked up and apparently working f...Very happy to see this plugin. We've got it hooked up and apparently working fine, but I have a question. Will this only find issue keys on commits to master? We aren't seeing git revision logs for commits to any other branches. Is there a way to enable this, or is it unsupported? If it's not supported, we care enough about this to be motivated to submit a patch...
Jun 10, 2009
J. Longman says:
Glad to hear you've gotten it working. To answer your question, I thought tha...Glad to hear you've gotten it working.
To answer your question, I thought that I had tested it and I remember it working but can't reproduce a case right now. Thinking about it - it may have worked when I was doing the fetch with a cron job and JGIT-1 changed that behaviour. I'll keep looking.
Jun 10, 2009
Ken Miller says:
Appreciate the attention. Let me know if I can help in any way.Appreciate the attention. Let me know if I can help in any way.
Jun 10, 2009
J. Longman says:
I'm not going to have a lot of time to look at it soon - in terms of open source...I'm not going to have a lot of time to look at it soon - in terms of open source projects that I need to look at in order to support work there's something I need hudson to do first.
A workaround would be to add another git repository which is tracking each branch which you wish to follow. While untested, it should work.
If you or anyone has time, the code that is relevant is in the GitManagerImpl and the RevisionIndexer. A bonus would be to show the branch in the UI, but is not urgent since you can always click on the gitweb reference. Some thought should be given to possibly explicit inclusion/exclusion of branches, depending on how much cruft accumulates in your repository.
Jun 19, 2009
Ken Miller says:
If you have a moment, would you mind fleshing out the build instructions a bit?...If you have a moment, would you mind fleshing out the build instructions a bit? I've been out of the java world for a few years, and so I'm new to Maven (as well as Jira and its plugins). Are there prereqs beyond maven and java? I managed to make a little progress by adding the atlassian public repo to the pom.xml file, but there are still a few jars it can't find.
Jun 19, 2009
J. Longman says:
I'll try to do a fresh checkout and record what I've done. My first thought is ...I'll try to do a fresh checkout and record what I've done. My first thought is that maybe you're not getting the jgit jar (the real jgit, i.e. java-git api, not jira-git, of course)
Jun 19, 2009
J. Longman says:
I suspect what you need is to make your settings.xml to include the following re...I suspect what you need is to make your settings.xml to include the following repositories (see end of comment) - alternatively a profile.xml could be added to project, which I can't do this minute. Settings.xml should be in your ~/.m2 (or M2_REPO or whatever) and the rest of the file looks like http://confluence.atlassian.com/display/DEVNET/Example+settings.xml
I validated this by doing mv ~/.m2 ~/.m2backup, I copied the settings.xml file form .m2backup to .m2, then
Now I'm missing:
Javax jars are typically painful, you generally need to find them on sun and inject them into the maven repository as detailed when you run mvn. Any of these if you find the jar then mvn tells you how to inject it into the maven repository, so its not so bad for just 3 files.
<profile> <id>jnolen-devnet-profile</id> <activation> <activeByDefault>true</activeByDefault> </activation> <repositories> <repository> <id>atlassian-public</id> <url>https://maven.atlassian.com/repository/public</url> <snapshots> <enabled>true</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </repository> <repository> <id>atlassian-m1-repository</id> <url>https://maven.atlassian.com/maven1</url> <layout>legacy</layout> </repository> <repository> <id>sun java maven repository 2</id> <url>http://download.java.net/maven/2</url> </repository> <repository> <id>iBiblio Maven2</id> <url>http://mirrors.ibiblio.org/pub/mirrors/maven2/</url> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>atlassian-public</id> <url>https://maven.atlassian.com/repository/public</url> <snapshots> <enabled>true</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </pluginRepository> </pluginRepositories> <properties> <downloadSources>true</downloadSources> <downloadJavadocs>true</downloadJavadocs> <!-- Uncomment this and specify the location on your file system where your clover license is located. <clover.licenseLocation>/path/to/clover/license</clover.licenseLocation> --> <atlassian.pdk.server.url>http://localhost:1990/confluence/</atlassian.pdk.server.url> <atlassian.pdk.server.username>admin</atlassian.pdk.server.username> <atlassian.pdk.server.password>admin</atlassian.pdk.server.password> </properties> </profile>I don't have time to check this now, but once those are injected, re-running mvn -Pplugin-debug should start a webserver on localhost:1990/confluence and you can start to play with the developer environment.
Jun 23, 2009
Ken Miller says:
Thanks, this helped a lot. I'm able to build now. It may take a little while t...Thanks, this helped a lot. I'm able to build now. It may take a little while to get this working, unfortunately, since AFAICT I need to modify the revision index to record not just one revision per repo, but one per branch per repo. Does that sound right? A bit more involved than I'd figured/hoped, but here goes.
Aug 18
J. Longman says:
I upgraded jgit to 0.5.0 principally so I could use the maven release functions,...I upgraded jgit to 0.5.0 principally so I could use the maven release functions, but I'm hoping there's something in the APIs that will make this easier.
later, j
Aug 20
J. Longman says:
This doesn't look like it would actually be that hard. It should just be a matt...This doesn't look like it would actually be that hard. It should just be a matter of getting the list of branches (ie. their HEADs) which the jgit command line tool does. Then for each of those walking revisions from the last destination to its HEAD. It also requires a new field in the lucene db to store the branch and then the template to display it. So it all sounds like incremental work. Unfortunately I've gotta sleep.
Jul 30, 2009
Jeppe Toustrup says:
Thank you for the plugin, it works just fine! However, I have made a few co...Thank you for the plugin, it works just fine!
However, I have made a few corrections to the plugin (with my limited Java knowledge), those are:
Here is a patch for the changes:
Index: trunk/src/main/java/com/xiplink/jira/git/GitManagerImpl.java =================================================================== --- trunk/src/main/java/com/xiplink/jira/git/GitManagerImpl.java (revision 33256) +++ trunk/src/main/java/com/xiplink/jira/git/GitManagerImpl.java (working copy) @@ -277,6 +277,8 @@ final File gitDir = new File(current, ".git"); if (isGitDirectory(gitDir) != null) return gitDir; + if (isGitDirectory(current) != null) + return current; current = current.getParentFile(); } // see if it is a bare repository Index: trunk/src/main/java/com/xiplink/jira/git/linkrenderer/LinkFormatRenderer.java =================================================================== --- trunk/src/main/java/com/xiplink/jira/git/linkrenderer/LinkFormatRenderer.java (revision 33256) +++ trunk/src/main/java/com/xiplink/jira/git/linkrenderer/LinkFormatRenderer.java (working copy) @@ -100,7 +100,8 @@ if (changesetFormat != null) { try { String href = StringUtils.replaceAll(changesetFormat, "${rev}", "" + revisionNumber); - return "<a href=\"" + href + "\">" + revisionNumber + "</a>"; + String shortRevNumber = revisionNumber.substring(0,7); + return "<a href=\"" + href + "\">" + shortRevNumber + "...</a>"; } catch (Exception ex) { log.error("format error: " + ex.getMessage(), ex); } Index: trunk/src/main/resources/templates/plugins/git/projecttabpanels/git-project-tab.vm =================================================================== --- trunk/src/main/resources/templates/plugins/git/projecttabpanels/git-project-tab.vm (revision 33256) +++ trunk/src/main/resources/templates/plugins/git/projecttabpanels/git-project-tab.vm (working copy) @@ -107,7 +107,7 @@ <td bgcolor="#ffffff" width="10%" valign="top" rowspan="3">$commit.timePerformed</td> <td bgcolor="#ffffff" width="10%" valign="top" rowspan="3">$!{commit.revision.authorIdent.name} / $!{commit.revision.committerIdent.name}</td> <td bgcolor="#ffffff">#makelinkedhtml($commit.revision.getFullMessage().trim())</td> - </tr>/$! + </tr> <tr> <td bgcolor="#f0f0f0"><b>$i18n.getText("git.project-tab.files-changed")</b></td> </tr>And a compiled version for those who don't want to mess with that stuff: jira_git_plugin-0.4-SNAPSHOT.jar
(I took the liberty of calling it version 0.4 in order to avoid to much confusion, I hope that's okay
)
Jul 30, 2009
J. Longman says:
Thanks Jeppe! I'll look at integrating your changes soon. I'll take a closer...Thanks Jeppe! I'll look at integrating your changes soon.
later, j
Jul 31, 2009
Jeppe Toustrup says:
You're welcome. I see what you mean in regards to the bare repository thing. I ...You're welcome.
I see what you mean in regards to the bare repository thing. I somehow missed that there was a code block right underneath which was supposed to find this. This does however not work if you give a path like the following as root: /git/Repository.git/, which I would consider being a correctly named bare repository.
Maybe it was better if the repository root path was stripped for any trailing slashes, and then checked if the path ends on .git. That way we would know if the user is trying to address a bare repository or not, and could improve the logic based on that. What is your thoughts on that?
By the way, another thing I would like to have made, but I could figure out how to, was to have the repository name parsed in the URLs for webgit, as ${rev} does. Then you could simply set up a "template" for webgit links, and use that for all Git repositories you may have - as long as they are located on the same server. I need to read up on Velocity in order to find out how to expose the repository name to the template.
Jul 31, 2009
Jeppe Toustrup says:
I had a go at making the findGitDir a bit more intelligent, in order to make it ...I had a go at making the findGitDir a bit more intelligent, in order to make it find the correct directory in the first guess. Here's the code for the function:
private static File findGitDir(String root) { File current = new File(root).getAbsoluteFile(); if (current.getName().endsWith(".git")) { if (log.isDebugEnabled()) log.debug("checking for gitdir: " + current.getAbsolutePath()); if (isGitDirectory(current) != null) return current; } else { File gitDir = new File(current, ".git"); if (log.isDebugEnabled()) log.debug("checking for gitdir: " + gitDir.getAbsolutePath()); if (isGitDirectory(gitDir) != null) return gitDir; } return null; }So it simply checks if the path given ends with .git, and if it does then it checks if the directory pointed to is a Git folder, otherwise it checks the path + .git as before. I don't really see a need for the function to try to find the .git directory on it's own, since people 'should' be able to specify the correct path in my opinion
Regarding your note about not having to specify the repository origin when adding the repository, then you could probably use the org.spearce.jgit.lib.Config functions or so in order to find the origin. Note though in regards to this, than when you have a bare repository there is no origin path, so it should probably not be specified for bare repositories.
I hope my (limited) work can help make this plugin better.
Aug 18
J. Longman says:
Your changes are in the new 0.4 release. Thanks! FYI plugins.atlassian.com all...Your changes are in the new 0.4 release. Thanks!
FYI plugins.atlassian.com allowed me to enter a contributor but forced me to enter an email, so I put something meaningless as an email.
Aug 19
Jeppe Toustrup says:
Great, that will make it easier for me to do any further work on the plugin, in ...Great, that will make it easier for me to do any further work on the plugin, in case I make any more changes to add.
You can see my e-mail address at my profile page here in Confluence, if you want the correct address in there. I can however not see where it should be shown...
Aug 19
J. Longman says:
Atlassian has a fancy new plugins page - a lot of the information here should be...Atlassian has a fancy new plugins page - a lot of the information here should be managed there and then this page can be left for more wiki'ish things.
see: https://plugins.atlassian.com/plugin/details/4984
and for your name in lights: https://plugins.atlassian.com/plugin/details/4984?versionId=10911
Aug 19
Jeppe Toustrup says:
Hmm, I can't see any difference between those two links. It may not be completed...Hmm, I can't see any difference between those two links. It may not be completed yet, or the informations are not visible for other than the plugin owner. It doesn't however matter to me, so don't worry about it
Sep 16
Joyjit Nath says:
One of the problems of this being a Jira "plugin" is that uses a "pull" model. i...One of the problems of this being a Jira "plugin" is that uses a "pull" model. i.e. Jira periodically polls the repository to watch for stuff that has changed. The reason this is a problem?
-- Not "real time"
-- If the commit message does not have the correct syntax of magic marker, the commit still succeeds.
Instead I wanted an integration that is more tightly coupled, similar to the way Trac integrates with SVN ( http://trac.edgewall.org/wiki/TracSubversion ).
To that end, I have written up a script, called .... "git-jira-hook".
It uses the "push" model instead, and git notifies Jira (using the SOAP api) whenever commits are made.
Please check it out below and let me know what you think:
http://github.com/joyjit/git-jira-hook
Sep 18
J. Longman says:
It's a Jira plugin, not a Jira "plugin". But looking at your site, I think you'...It's a Jira plugin, not a Jira "plugin". But looking at your site, I think you're just misusing quotation marks. Careful, it appears like you are using sarcasm. Maybe this is a cultural affectation?
I think you are right that some people will prefer your solution over what Atlassian modeled and I imitated. I will add a link to your solution at the top of my page, and I'd encourage you to register it on plugins.atlassian.com. It may not fit their standard model but should be acceptable.
Some comments, however:
First, I think that the commit policy should be kept separate from your commenting model. It is definitely of value, but different organizations may wish to implement it at different levels. E.g.: Hook aborts any commits that don't match the pattern (a regex works for this, btw); which don't exist (rpc call required); not assigned to [author|committer]; not [open|in progress|resolved]. Any combination. The hook permits commit but emails a mailing list with a warning, is another option. We haven't dealt with this yet but my understanding is there is also a question of how the hook handles commits vs merges, a more subtle point. So I'd recommend you separate the two functionalities.
Second, the difference between a separate pane vs comments:
Third, the pull-model isn't usually time-relevant:
The git log can be checked once a minute. We don't need an update frequency higher than this - indeed, when a developer says, "it hasn't appeared yet" it's because they're talking to someone who just committed it. If you know it's there you can wait a couple of minutes (or check gitweb).
Hudson has the same set of alternate solutions. (Hudson Jira vs Marvelutions). Right now, I like BOTH. I like the original plugin because it provides a permanent record in comments - but we only turn it on for OFFICIAL builds, otherwise its too noisy. Marvelution's plugin is in a separate pane and tracks ALL builds and is great. However, if you delete a build the record is no longer visible in their plugin, which means you lose history. Same thing in Jira Git plugin, you edit the repository, rare on an official repo, still, it could re-index and lose any removed commits. But you don't do this often, and when you do, you don't generally want that history.
It may be that there's more value offered by this plugin than you think, and vice versa, that I know your hook does. It's good that people can choose.
Sep 21
Phil Lawrence says:
The git hook approach seems to address the problem JIRA Git Plugin has with trac...The git hook approach seems to address the problem JIRA Git Plugin has with tracking multiple branches. I do agree the large amount of noise generated in the JIRA comments would be a problem.
I'm very new to JIRA, so this question might be phrased incorrectly, but would it be possible to use only the seperate tab feature from the JIRA Git Plugin, and then use a Git hook to actually populate the tab?
Sep 21
Joyjit Nath says:
"it appears like you are using sarcasm" Not really. Who knew placement of quote..."it appears like you are using sarcasm"
Not really. Who knew placement of quotes can imply so much?
Kidding aside, thanks for your comments.
I think whether you use a Jira plugin or a git-hook to integrate Jira with git depends on your usage model. In our case, we were quite used to using Trac with SVN and were very happy with it. Once we switched to Jira and git, I tried to continue emulating the Trac model, and hence the scripts.
I don't really see "commit noise" as noise. Obviously its a matter of personal preference and/or company policy, and some people will disagree. In our case, we really would like to get notified every time a commit is pushed to our "public" git repository and git-jira-hook solves this problem as well. When a git push is made, the series of commits updates the Jira ticket(s), which in turn causes Jira to send out a nicely formatted email. By clicking on links embedded in that email, the recipient can now look at the exact git commit(s) as well.
To answer your other question "You do comment for commits contained in the merge right?" -- I don't think I understand your question clearly. In the event the "merge" caused a commit, this commit would have to have the Jira magic markers embedded or else the commit would not succeed. Does that answer your question, or were you asking something else.
Sep 18
J. Longman says:
A hook like yours could theoretically be used to trigger a re-index for my plugi...A hook like yours could theoretically be used to trigger a re-index for my plugin and that would also address the timeliness concern.
Overall I think your hook looks pretty good, and is reasonably clean. I could see using some of the code to warn developers when a commit hasn't met standards (e.g. lacking a JIRA issue), but we merge third-party repositories and can't be dictatorial about necessitating JIRA commit issue numbers.
Nov 06
Indraneel Chowdhury says:
I have added git branch support to the plugin. We have been using the modified v...I have added git branch support to the plugin. We have been using the modified version of the plugin for about a couple of months and it's been working fine. I have made changes to the following files:
Please see if these changes can be merged. Attaching the source files.
Nov 06
J. Longman says:
Hi! Awesome. I've just started to look over it and it looks like your code is b...Hi! Awesome. I've just started to look over it and it looks like your code is based on 0.3-SNAPSHOT, but the changes since then were minor.
I'm scanning it now... it also looks like you've eliminated the repository id, meaning the ability to identify which repo sourced a commit would be lost. Is that interpretation correct?
I'll build it and play with it to see what it looks like.
Nov 06
J. Longman says:
I've ported the changes to 0.5-snapshot - I'm getting a null pointer on a repo i...I've ported the changes to 0.5-snapshot - I'm getting a null pointer on a repo id during retrieval of commits for an issue. As I mentioned above, I'd seen that you removed the repoId from the lucene document, so maybe this line should be commented out or something.
(In my tests I'm running a single repository with many branches and 2 projects. The git repository is actually our live repo, but the issues are all fabricated and imported from a csv file and are pretty bogus. The master branch case worked, but the error was an commit/issue NOT on master and was also the other project.)
I'll try to get this going this weekend - I'm willing to sacrifice multi-repo in the short term, and I'd be willing to put this out as it is as I think it immediately adds value.
The features that (I think - maybe I'm missing something) need to be added are the ability to scope the branches searched (it takes over 5 minutes on my repo easily for a scan, but it is scanning EVERY branch afaict) and showing which branch(es) the commit is in in the git commit tab. (I'd still be willing to release this without those features however).
Nov 07
Indraneel Chowdhury says:
True, the modifications I made does not show which branch the commit was made to...True, the modifications I made does not show which branch the commit was made to in the git commit tab. That can be some future work (maybe for me :-) ).
Nov 09
J. Longman says:
I spent Sunday looking at the branch information problem and ran up against two ...I spent Sunday looking at the branch information problem and ran up against two problems:
I'm not even sure why you, Indraneel, removed the repository?
In the short term for those who need multi-branch I'd recommend using Indreneel's code. Hopefully 0.5 will be out this week with multi-branch support.
Nov 07
Indraneel Chowdhury says:
I did sacrifice the repository id for the branchesI did sacrifice the repository id for the branches
Nov 06
Ken Miller says:
Chiming in that this has been working really well for us. Thanks Indraneel.Chiming in that this has been working really well for us. Thanks Indraneel.