We all know GitHub is a fantastic way to collaborate on software. It has a fairly basic issue tracker, but it serves most purposes well enough. But if your code base is spread across several repositories, it can be difficult to know how you’re doing, from a management perspective. Octoherder can help with that.
Huboard provides a nice kanban style interface for your project. Crucially, it lets you link repositories, letting you see tickets across your project rather than just for one repository. It also lets you view your tickets at a milestone level. That’s great. But things change: milestones are added, or have their dates changed. And now you have ten repositories to edit. Not fun.
And that’s where octoherder helps out. It uses a YAML file containing the canonical layout of your project – a master repository, some linked repositories, huboard column names, labels common to all repositories, and milestones. Bootstrapping octoherder is easy -
$ octoherder -r me/master-repo -o my_project.yml -u myname -p
- at which point
my_project.yml
looks something like this:
---
master: me/master-repo
repositories:
- me/sub-repo
- other/sub-repo2
milestones:
- title: milestone-1
state: closed
- title: milestone-2
due_on: 2011-04-10T20:09:31Z
- title: milestone-3
state: open
description: The third step in total world domination.
# Tags used by Huboard to define its columns:
columns:
- 0 - Backlog
- 1 - Ready
- 2 - Working
- 3 - QA
- 4 - Done
# Tags used by github-planner (https://github.com/frankshearar/github-planner):
labels:
- 0.5
- 1
- 2
- 3
- 5
- 8
- 13
Now if you need to, say, extend milestone-2, just edit that milestone’s
due_on
field and
octoherder -i my_project.yml -u myname
will apply the change to the master repository and across the linked repositories!