Git Post-receive hook with part of work tree

Question

I would like to use git to deploy to a website to a testing server. My website is a wordpress theme built with gulp and the repository looks like

theme.git/
-- gulpfile.js
-- src/
-- build/

I've followed the steps explained here and here which are- set up a bare repository on the server, configure the location of git work tree and write a post-receive hook to checkout the repo to that location.

The problem is I'm only looking to move or copy the build/ folder to it's location on the server. My only thought was to write a post-receive hook to that pulls the repo to one work tree location (because I think I read that bare repos don't typically have a work tree at all), and then cp's the build folder into wp-content/themes/

It seems unnecessarily complicated so I'm wondering if there's a more efficient / more common way to go about it. Thanks!

Answer 1

Your approch for using git so extensively for the deployment seems a bit weird, mainly because git is primary a source code management system, not a deployment tool. It is true that you can do many kind of weird stuff with git hooks, but for some reason or another I feel those a tendency to return to haunt you.

Normally I would recommend you to use somekind of continuous integration tool for the job. One possible workflow, which I could use myself, would be

1. Store your theme files in a public repository at GitHub. It's free, there probably are no great secrets in your theme source code, and as an additional bonus you could even open source you theme.
2. Set up a CI job with Travis CI for your repository. You basicly get a free build machine instance in the cloud, and you can do all sorts of stuff before or after build. You could eg. run gulp build (or whatever your task name is) there, so you wouldn't have to store the build directory in the git repo at all.
3. In the Travis after_success hook you could then copy the build directory to the target server for example by using scp. Here is an example of doing the very same thing with FTP. Travis supports encryption of sensitive data, so you don't have to worry (at least so much) about storing username and password in the git repo.

That flow is useful when you want to deploy the build everytime you commit something to the git repo. BTW, when you use it for the first time it really feels like magic: "I just made this git push, and now the change is already live on my server."

However you mentioned that you want to deploy the code to a testing server. It is true that CI tools (such as Travis) can be used to maintain a flow between different deployment steps, out of which many are testing servers. One example flow for large projects could be

development -> tests passing? -> release -> tests passing? -> integration -> tests passing? -> staging -> tests passing? -> production

...where the flow could be either partly or fully automated with a CI tool.

However you made it sound like that in your case deploying of build is kind of a one-time thing, which you sometimes just want to do manually. (I apologize if I misinterpreted you.) For these kind of one-time tasks the use of shell scripts or task management tools is more fitting.

You mentioned that you're already using gulp. That's a very handy tool for the job, especially because you can easily combine different "streams of tasks". You could have one task for building the theme (gulp build) and another for test server deployment (gulp deploy-test), which just extends the build task with an additional step for copying of files to the test server. gulp-scp looks like a fine plugin for the task (I haven't used it myself though, it was just the first search result from google). If that does not work out, you can always call scp manually with gulp-shell or similar.

You could even parametrize the deployment tasks so you could do something like: gulp deploy --test and gulp deploy --production

There you go, this was your first lesson in devops. There's a whole world of things to learn if this kind of task automation in software projects sounds interesting to you.