To do this, I’ve been using a centralized git repository using gitosis and gitweb.  Because it’s behind the Backcountry firewalls, there is no easy way to share our repository data.  However, there are some great git repos at github, which I highly recommend.

Anyway, we do the hub-and-spoke model with our git repositories.  Meaning that we have a central repository where much of the data is stored so everyone can get access.  Of course, though, most people clone these repositories and work on the code where they choose.  Because we have several people pushing puppet data to our repository, which has been on subversion until 2 weeks ago, I am keen on making sure the puppet code we push to the central repo is at least syntactically valid.

Git Hooks: The skinny

Essentially, the key here is to understand is that git, like many other popular revision control systems is distributed.  This means that many people keep repos locally and push to the central repository after many many commits (or just one or two).  Git keeps the history in a clean way and all of the commits are pushed and tracked.  Essentially, we need some way to validate the data coming in from an outside source.  Enter git hooks.

There are several git hooks, but three that are quite critical to this scenario; pre-commit, pre-receive and post-receive.

The first, pre-commit is specific to the repository where the commit is taking place, such that a validation of the puppet syntax here is useful to help the person writing the puppet rules.

Next is post-receive which is generally useful for sending out emails after a successful push.  It would list the files and the diff of each in an email to those who wish to know about the commit.

And finally, the least documented of the bunch; the one with the least amount of examples, pre-receive.  The pre-receive hook has some really awesome power, but without knowing the git commands backward and forward, it can be very frustrating to get working.

The value of the pre-receive hook

Whenever a push is made to the centralized repository, you don’t just want to let any willy nilly commit crawl in there.  You can’t trust that the author of the commits did his part to validate the code.  So you need to at least do some basic checks.  That is what the pre-receive hook does.  In the following example, I am parsing files that end in ‘.pp’ with puppet syntax validation as you would do from the command line.

#!/bin/bash

while read old_sha1 new_sha1 refname anothervalue ; do
    list=$(git show --pretty="format:" --name-only $new_sha1 | grep -e ".pp$")
    for tmpfile in ${list}; do
        git show ${new_sha1}:${tmpfile} | puppet --color=false --confdir=/tmp --vardir=/tmp --parseonly --ignoreimport
        if [ "$?" -ne "0" ]; then exit 1; fi
    done
done

exit $?

The above script, placed in a bare repository at hooks/pre-receive with the execute (+x) bit turned on, will get a list of files that end in ‘.pp’ and run the puppet validator for the newest commit in the push.  Essentially, I can validate someone else’s puppet code in just a few seconds and return a failure if it doesn’t succeed.  With git hooks, a failure means no commit/push/etc will actually happen.

I sure hope this helps someone else to understand pre-receive hooks as well as git hooks in general.  If you have any helpful suggestions or comments, those are most welcome as well.

Cheers,

Herlo

I apologize for the last minute notice.  I’m hoping to have the Basics of Puppet presentation next month.

Cheers,

Herlo

What is Puppet?  (for the curious and uninitiated)

Puppet is an open-source next-generation server automation tool. It is composed of a declarative language for expressing system configuration, a client and server for distributing it, and a library for realizing the configuration.

More information is available here: http://reductivelabs.com/trac/puppet/wiki/FrequentlyAskedQuestions

———————————————————————————-

We meet in conference room A on the lower level of the Salt Lake Library.  Head down the stairs, make a left turn.  The conference room  is directly under the foyer area (the area with all the shops on the 1st level)  If you aren’t clear, ask the information desk.

Also, our meetings should be posted on the Electric Signs by the entrance to the library on the first floor.

Cheers,

Herlo