peg: review tool review request - Mailing list pgsql-rrreviewers
From | Greg Smith |
---|---|
Subject | peg: review tool review request |
Date | |
Msg-id | 4B062786.7010706@2ndquadrant.com Whole thread Raw |
List | pgsql-rrreviewers |
I've been working for years now on various scripts to automate setting up test installs of PostgreSQL for everything from patch to performance testing. This month I pulled them all together into one unified framework I've named "peg", and it's now available on github: http://github.com/gregs1104/peg/ I thought this list was a good subset of people to announce it to initially, as I think it's ideal for reviewing one or more patches efficiently. Basically, you create a single directory to put all your PostgreSQL work into (if you name it "pgwork" it will automatically find it even), and the script can do everything else needed to grab a repo, build a cluster, and start the database. You get a subdirectory for each of the main components in a PostgreSQL install (source code, binaries, data) and another underneath those for each project . Here's how simple you can get going with CVS: cd mkdir -p pgwork peg init test . peg build psql That's it; you'll get a standard debug/assert enabled source build from the master PostgreSQL repo, with a checked out copy you can apply patches to and tinker with, and you'll have the usual PGDATA/PGLOG environment variables exported to your shell along with a PATH having the new binaries in front. Once you've got the environment setup, it's this easy to get back into it again after something like a reboot: . peg switch It will remember what project name you told it to use last, start the server, and off you go again. It tries very hard to guess what you want it to do and just take care of it, while still allowing that behavior to be overridden. I also provide simple aliases like "start" and "stop" to do routine server cycling, without even running the big script. At this point you might be thinking this is only a hundred or two lines of code. Not even close; it's filled with every little workflow optimization, good default, and detection method I know in this area. There's 64 distinct if statements alone, each of which tries to detect and guess some behavior. I also support git and a simple tarball file as repo sources. Amusing for a project hosted at github, the git support is probably the weakest of the three right now. I'm not 100% happy with how I handle that just yet, I've been offline and working mainly with the alpha2 .tgz for much of the recent development. The documentation is pretty comprehensive already, and I do note which of the examples provided I've tested or re-tested recently and which haven't been (and therefore might have problems). The code is a little raw still, is probably filled with bash and Linux isms, and it might take you a minute to see how it all fits together. But I think you'll find a time savings very soon if you try it out. And since I'll be living inside the environments it generates for the near future, you can be sure I'll eventually get all the bugs out of there. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
pgsql-rrreviewers by date: