Issuezilla to JIRA migration

This page has instructions on how to do the issuezilla to JIRA migration.

Here is our internal testing instance of JIRA: http://ci.mifos.org:8080/

The basic procedure that has been followed is outlined on the pages written up by Michael:

http://kenai.com/projects/issuezilla-to-jira/pages/ToolSetup

http://confluence.atlassian.com/display/JIRA/Jelly+Tags

Jelly tag reference:

http://www.atlassian.com/software/jira/docs/v3.13.2/jelly.html

Tool Setup

I have done the steps on ToolSetup. Prerequisits and JIRA JVM Configurations should not have to be repeated as long as we're using the same JIRA instance that we are now on birch.

When the time comes to freeze issuezilla and do the final migration, then the "Download Issuezilla XML & Attachments, and generate Jelly" section will need to be repeated. Step 1 just tests that the jar can be run. When I ran steps 2,3,4, it looked like this:

java -jar jelly-generator-1.0-SNAPSHOT-jar-with-dependencies.jar downloadXML download/ mifos vanmh <vanmh password> net1java2dot3xml.cgi
java -jar jelly-generator-1.0-SNAPSHOT-jar-with-dependencies.jar downloadAttachments download/
java -jar jelly-generator-1.0-SNAPSHOT-jar-with-dependencies.jar jelly download/ mifos admin mifos

where the only thing to fill in is to replace vanmh with your own java.net userid and <vanmh password> with your java.net password.
I ran these commands in /home/vanmh/jira_migration on birch. The jelly xml files that get generated are in /home/vanmh/jira_migration/download/JIRA-Jelly.

I have modified the jelly generator source code to include fixVersions and handle merging 'unscheduled' and 'Unscheduled' fix versions into a single 'Unscheduled' fix version is the v01 patch/jar. The patch used to generate the v01 jar file in /home/vanmh/jira_migration is attached to this confluence page.

Patch 02 includes the migration of issuezilla Keywords to JIRA Labels.

Jelly Tags

Steps 1-11 have been done on our JIRA instance and should not have to be repeated. The only difference between what is documented and what I did is that in step 7.4 I had to change the Destination Step for Stop Progress from "Verified" to "Reopened" in order for the import to work, since the migrated transitions need to transition out of either "Reopened" or "Open".

From this point, to reimport, you just need to follow the steps in the "Re-importing" section. For step 3 of "Re-importing", you start with step 12 above and go through 16. Note that in step 15, you edit "Issue Type Scheme" not "Issue Type Screen Scheme" In my case, doing the jelly import meant pasting "/home/vanmh/jira_migration/download/JIRA-Jelly/jira-newproject-jelly.xml" into the "Jelly Script file path" edit box and then deleting the default XML from the "Jelly Script (XML)" edit box.

Starting and Stopping JIRA

The JIRA instance is installed in /usr/local/share/apps/jira (let's call this JIRA_HOME)

To control JIRA use:

sudo /etc/init.d/jira start
sudo /etc/init.d/jira stop
sudo /etc/init.d/jira restart

Sending Migrated Data to Atlassian

After getting a successful load into our Jira instance, the idea is to use the "Backup Data to XML" option to dump the JIRA issues to XML (zippped) and then separately to zip up the jira attachments directory which is in /var/local/jira/attachments. My guess is that they would also need to know about any plugins we depend on like the "Labels" plugin. And if we decide to use the watcher plugin, then that one too.

The XML dump and the attachments gzip file have been uploaded for Atlassian to load by using the "cadaver" WebDav tool to upload them, from /home/vanmh/jira_migration :

cadaver https://mifosforge.jira.com/webdav

put jira_mifos_backup.zip

put jira_mifos_attachments.tar.gz

Reference page: http://confluence.atlassian.com/display/JIRASTUDIO/Uploading+SVN+Dumps+via+WebDAV#UploadingSVNDumpsviaWebDAV-AccessingyourWebDAVdirectoryinLinux\\