I wanted to set environment variables with an Execute Shell step, and then be able to pass them as parameters to the benchmarks build.  I wanted to pass the git commit id and timestamp to the benchmarks build for recording.  The Git SCM Plugin doesn’t provide that information to Hudson.  The Parameterized Trigger plugin is able to handle environment variables that are set by Hudson itself.  However, when trying to set them in the Execute Shell step, it didn’t pick up the newly set environment variables.  At this point I looked through the available options.  I saw that I could set the Parameterized Trigger to read from a parameters file.  I tried writing out a parameters file from the Execute Shell section, and reading it in using the Parameterized Trigger plugin.  Success!

Here are the commands I used to write out the properties file:

echo "COMMIT_ID=$(git rev-parse HEAD)" > params.properties
echo "COMMIT_TIME=$(git log -1 --pretty=\"format:%ad\")" >> params.properties

In the end, it worked out pretty well.  After these commands are run, a params.properties file is created.  The Parameterized Trigger plugin is setup to read params.properties, and the information moves on to the next build.

Features (that appeal to me):

These features are of DVCS in general, Bisect may be git specific.

• Local Commits – Even if you don’t have access to the repository, you’re still able to commit to your local copy.  So even without commit access, you still have all the tools a cm system provides available to you.
• Entire revision history stored locally. – Let’s face it, hard drive space it cheap these days, and network hiccups happen from time to time.  It’s nice to be able to have your revision history there when you need it.  With SVN, without a path to the server there is little you can do.
• Bisect – While I haven’t used this, it seems like a very interesting feature.  It allows you to specify a start and a stop revision.  It then helps you track down when a bug was introduced.  I may include something more about this after I’ve used it, but it still looks like an interesting feature.

Starting out:

Make sure you have git installed before starting here.  I’m assuming git is installed, and you are a little familiar with the commands.  Here are some links to some excellent resources to get you started if you’re not at that point yet:

• http://git.or.cz/gitwiki/GitCheatSheet
  • When starting out with any new command line tool, I see if there is a cheatsheet online for it.  It’s always good to help you get acquainted with some of the commands.  In general, a good starting point.
• http://gitready.com/
  • This is a really cool resource I found while on my adventures in git.  It helped me figure out how to revert files, which wasn’t entirely clear from the commands.
• http://git-scm.com/course/svn.html
  • It was useful to see some of the svn commands that I’m used to, and their git counterparts.

Well, now that you’re somewhat familiar with git, let’s get started on with github.  Now, the main reason for posting this is because as a new user it didn’t seem that clear what I need to do to actually push to a repository.  After you’ve been given access to, or created, a github repository, you must set your username and email for github to use.

Instructions on that can be found here: http://github.com/guides/tell-git-your-user-name-and-email-address

Now, here is the part that really wasn’t clear to me.  You need to setup an ssh key to github as part of their authentication.  I don’t know if this is correct, but I think of this as a layer of encryption that happens to make sure my files get to github unaltered. (similar to PGP for email)

Instructions for this can be found here: http://github.com/guides/providing-your-ssh-key

Now that you’re all setup, you’re ready to do some commits and then a push to the server.  Have fun in the world of git.