I figured it would be a good idea to start posting some of the scripts that I find useful - especially when doing Ruby / Rails coding. These scripts will end up in (where else) a Github repo.
The first is gil, a handy script for generating changelogs from your git repo AND your Lighthouse. It was written to answer the question "what is going to be fixed or added in the next release?"
Let me explain. You can get a list of changes by issuing a git-log command, like this:
git-log v2..HEAD
However, what you get from that may not be suitable to publish directly as a changelog, or to send a customer. This is where Lighthouse hooks come in handy. Assuming you have these hooks setup (the easiest way is to host on github) you can then associate a particular commit with a Lighthouse ticket (and mark it resolved all at the same time) by putting something like this in your commit message:
[#1 state:resolved]
What gil does is to pick those handy strings out of your commit history and to use the Lighthouse API to fetch details of the tickets. So if you were to run
gil v2..HEAD --account=simonjefford --project=99999 --token=<your lighthouse beacon token>
you would end up with a list of Lighthouse tickets that were resolved by commits since you tagged v2. Which is pretty neat. But passing in all that lighthouse information each time you run gil is a PITA right? So, put that information in your .git/config file:
[gil]
account=simonjefford
project=99999
token=<your lighthouse beacon token>
Now you can just run gil v2..HEAD. Much nicer.
If you use Capistrano, gil becomes even more useful if you get cap to automatically tag your deployments:
namespace :deploy do
task :tag_release do
system "git tag #{release_name}"
end
end
after "deploy", "deploy:tag_release"
Assuming your deploy works OK you will end up with a tag named something like 20080508224225. Then you carry on coding, resolving lots of lighthouse tickets. To answer your boss when he asks "what's coming up in the next release" you can just run
gil 20080508224225..HEAD
