Moving from Redmine to GitHub Issues

Recently, we moved from Redmine to GitHub Issues for sake of transparency/consolidation.

Taking advantage of the RedMine and GitHub APIs, we wrote an unpolished/try-to-get-the-job-done-by-wednesday python program redmine2github to make the switch. The process was roughly as follows:

1. Copy each redmine ticket to an individual JSON file. Information included:
   • Comments (journals)
   • Relations
   • Child Tickets
   • etc
2. Manually created the following mappings. (All mappings are optional with the program)
   • Name Map between Redmine and GitHub users. This allows translation of Issue creators, Commenters, and Assignees
   • Label Map to translate Redmine attributes to GitHub labels. Note: the first column, “redmine_type” is not used by the program–it’s a reference for humans. The file/program are “dumb” and don’t look for name clashes in the “redmine_name” column.
     • Note: By repeating columns 3 and 4, 2 or more “redmine_name”s may be translated to the same label. In the sample file, the first three Redmine Names: “New”, “In Review”, and “In Design” are all moved to the label “Status: Design”
     • IMPORTANT: If a label map is used, any “redmine_name” not on the map will be ignored. If a label map is NOT used, the “redmine_names” will be made into labels–but with no color attribute.
   • Milestone Map to translate Redmine “fixed_version” to a GitHub milestone. This works similarly to the Label Map with an import distinction below:
     • IMPORTANT: Differently from the label map, any Redmine “fixed_version”s not found in the milestone map, will be created in GitHub.
3. Ran the issue migration (mm.migrate_issues()) several times on newly created test repositories–that were then deleted. This helped work out bugs, etc.
4. Ran the issue migration against the real repository (this will “spam” users if you use a name map)
   • The migration creates an issue mapping file with JSON that maps { redmine issue number : github issue number }
   • Part of the mapping file:

{"4096": 647, "4097": 648, "4098": 649, "4100": 650, "4101": 651, "4102": 652, "4103": 653, "4104": 654, "4105": 655, "4106": 656, "4107": 657, "4108": 658, "4109": 659, "4110": 660, "4111": 661, "4112": 662, "4113": 663, "4114": 664, "4115": 665, "4116": 666, "4117": 667, "4118": 668, "4119": 669, "4120": 670, "4121": 671, "4122": 672, "4123": 673, "4124": 674, "4125": 675, "4126": 676, "4127": 677, "4128": 678, "4129": 679, "4130": 680, "4131": 681, "4132": 682, "4133": 683, "4134": 684, "4135": 685, "4136": 686, "4137": 687, "4138": 688, "4139": 689, "4140": 690, "4141": 691, "4142": 692, "4146": 693, "4148": 694, "4149": 695, "4150": 696, "4151": 697, "4153": 698, "4154": 699, "4156": 700, "4157": 701, "4160": 702, ....}

1. Run migration part #2 (#mm.migrate_related_tickets()) which updates the GitHub Issue descriptions with links to related and child tickets as defined in Redmine.
   • The result of the related/child tickets looks something like:
     
2. Run a script to update the Redmine tickets with a link to the new GitHub Issue.

The final migration, runs 1&2, took about 7 minutes for 700+ tickets. The results:

Overall, it worked fine. We have tweaked the labels since the initial mapping.