Question

I’m currently using gitolite, and in my post-receive hook I’m pushing to a (local) mirror if any incoming commits are on master.

Thing is, that mirror only exists because I want to automate deployment & testing on pushes to master: I can’t get at the index files in the work.git, so I push to a non-bare work repo to get a working tree, and run a completely separate post-receive hook.

I have two problems with this approach:

1. It feels dumb
2. If tests fail I get emails notifying me, instead of a rejected commit. (Not actually that big of a problem in terms of frequency, I just don’t like it.)

What’s the standard way of dealing with this?

Answer 1

It’s not dumb. Bare repositories are called bare for a reason. (I assume this is what you mean by “raw”.)

To answer your real question, I think you need to take a step back and ask what you’re actually trying to do. Do you want to reject a commit? Commits are local, nothing to do with pushing, so you’d have to run the automated tests yourself, whether in a pre-commit hook or manually. Do you want to reject a push? post-receive (or post-update) is too late for that but if you really wanted to, you could run the tests in a pre-receive (or update) hook. I suspect this is a bad idea though: tests take time, and I’m not sure you actually want to wait while your push hangs until the tests finish. (The deal about having separate repositories is not really relevant – the hook runs some commands, and whether or not they involve another repository, they have to finish before the hook exits.)

But maybe a more sustainable workflow would be: push to a pre-master branch, let the automated tests go, and when they complete, automatically push to the master branch. If the tests fail, the master branch won’t be updated, and you can get your email and go check it out.