Simon Jefford

I just pushed out gil as a gem onto rubyforge (my first gem - how exciting!) The magic incantation is of course:

sudo gem install gil

There is no functional difference between the gem and the script that I initially made available on github only. As I type this it hasn't made to the gem servers yet, but it should be on its merry way now.

UPDATE

Of course I forgot one major functional difference. I couldn't actually think of why anyone would want to pass all the lighthouse information as options on the command line so I removed that. Putting the information in .git/config is now the way to go - see the original blog post for more information. The gem itself is light on documentation at the moment.

This has been widely publicised - I found it on the Github Blog but you should also see the official Debian announcement.

This is how I updated my Hardy slices:

sudo aptitude update
sudo aptitude install openssh-client openssh-server

Trying to do a aptitude safe-upgrade told me that the openssh-client and openssh-server packages were going to be kept back for some reason so I fell back to explicitly upgrading. Say yes to the first solution that aptitude presents. A blue screen will eventually appear warning you that the machine keys are about to be upgraded. Say "OK". WARNING - this means the thumbprints in your known_hosts file or equivalent will not match which means your ssh client will warn you that the host may not be safe (or it may not let you connect at all IIRC).

Next you need to regenerate any user keys that you generated on your system. I did this as follows:

rm ~/.ssh/id_rsa*
ssh key-gen

Next run ssh-vulnkey. This will check all the keys in the usual locations - including those stored in your authorized_keys file. Any keys that come up as vulnerable need to be removed. Dud keys in authorized_keys probably indicate that there is a system that you use to connect to that box that needs to be patched and its keys upgraded.

Please note, this may not be the best or most efficient way of sorting out this problem, it's just the way that worked for me.

Next up is a simple Greasemonkey script (railslighthouselinker.js) that makes those Lighthouse hooks that Gil finds so useful into links when viewing a commit in Github. The script can be easily customised to setup links from any github project to any lighthouse project. Just change the "includes" metadata and the lighthouse url in the body of the script.

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