amida-tech/github-burndown-chart

#GitHub Burndown Chart

The original app got completely rewritten, see notes, thank you.

Displays a burndown chart from a set of GitHub issues in the current milestone.

##Features

1. Client side; easily hosted on GitHub Pages.
2. Private repos; use your GitHub API Token hiding it from public view if need be.
3. Off days; specify which days of the week to leave out from ideal burndown progression line.
4. Trend line; to see if you can make it to the deadline at this pace.
5. Multiple milestones; watch multiple milestones per repo, e.g. when using them for tracking epics.

##Quickstart

1. Choose a repo that you want to display burndown chart for.
2. Make sure this repo has some issues assigned to a milestone.
3. Put some labels on the issues looking like this: size 1, size 3 etc.
4. Close some of them labeled issues.
5. Visit http://radekstepan.com/github-burndown-chart/ following the instructions there.

##Configuration

There are three modes of operation balancing between usability & security:

1. Static Mode: you can just serve the public directory using a static file server or GitHub Pages. No config needed, just serve the app and point to your repo in the browser, e.g.: http://127.0.0.1:8000/#!/radekstepan/disposable. You are rate limited to the tune of 60 requests per hour.
2. Static Mode (Public Token): as before but now you want to use your GitHub Personal Access Token in the config. This will require you to specify the token in the config.json file as outlined below.
3. Proxy Mode (Private Token): you find it preposterous to share your token with the world. In this case you will need to serve the app using the Proxy Mode. Your token will be scrubbed from the config file and all requests be routed through a proxy.

All of the following fields are defined in config.json and none of them, including the file itself, are required. Just make sure that if the file exists, it is served with a correct MIME media type which is application/json.

###Size Label

The way we are getting a size of an issue from GitHub is by putting a label on it. The following regex (string) specifies which part of the label represents the number.

{
    "size_label": "^size (\\d+)$"
}

This is also the default label if no other is specified.

When multiple matching size labels are present on an issue, their sum is taken as the size of the whole issue. This allows you to mix & match (if you want) without creating too many labels in the GitHub interface.

###Token

Your personal access token token from GitHub. Get it here. Bear in mind that if you just statically serve the app, everybody will be able to see the token in transmission. If you would like to avoid that, use the Proxy Mode.

Using the token increases your limit of requests per hour from 60 to 5000.

{
    "token": "API_TOKEN"
}

###Off Days/Weekends

An array of day integers (Monday = 1) representing days of the week when you are not working. This will make the expected burndown line be more accurate.

{
    "off_days": [ 6, 7 ]
}

###Style

Edit the src/styles/app.styl file to change the look & feel of the app. The head of the file contains variables for easy editing.

##Proxy Mode

Use this strategy if you do not wish for your token to be publicly visible. Proxy mode routes all requests from the client side app through it, scrubbing the token from the config.json file. It is slightly slower than requesting data straight from GitHub of course.

Make sure you have CoffeeScript installed:

$ npm install coffee-script -g

Then start the proxy passing port number as an argument:

$ PORT=1234 coffee proxy.coffee

Visit the port in question in the browser and continue as before.

##Build It

If you would like to build a custom version of your app, edit the Gruntfile.coffee and run the following:

$ make install
$ make build

We are using the Bower package manager and Grunt task runner.

##Publish It

If you would like to track changes to build files in gh-pages branch, execute the following command:

$ make publish

It will checkout the gh-pages branch, copy the two build files from master and provided we have changed them locally, make a commit a push them to remote.

##Test It

$ npm install -d
$ make test

Each bugfix receives an accompanying test case.

##Rewrite

The original app got rewritten from a clunky server side to a (better) client side app. Some tests are also provided and more will be going into the future.

If you are upgrading from the previous app, then please bear in mind that config.yaml is replaced with config.json.

If you would like to use the original app, please refer to the original branch.

##Thanks

Thank you for using the app and your feedback/comments are very much welcome. Radek