On Tue, 2 Jun 2015 07:26:54 -0700 (PDT) Márcio Moreira <mar...@verdesaine.net> wrote:
> We are using Pelican, a static site generator, to generate our web > site. We write markdown formatted text files to a "content" folder > and Pelican generates HTML files to an "output" folder. > > Our goal is that the site could be edited by some collaborators > sharing its work through a repository on our local linux server. > Every time a commit is pushed to the local server, we wish the output > folder (or the complete working dir) is pushed to another server, a > production web hosting server: > > - Laptop A: complete working copy. > - Laptop B: complete working copy. > - Local Server: complete working copy for backup and centralized > repository. > - Web Hosting Server: only the output folder content (or complete > working copy, if we can´t send only the output folder). > > My question is how to setup the post-receive hook on local server to > push the output folder to the web hosting server. > > I have been following some posts on the web. They all set local > server as a bare repository, but I need it to host the complete > project: source and output files. It seems to me that a bare > repository can´t act as central repository for collaborators. Is it > right? OK, let's digest this piecemeal. First, you appear to make a false connection between your "output" directory and the type of the shared/public Git repository. Git in either setup does now know about this directory -- that knowledge belongs only in your static website generator. Now what you really want to have is a way to check the files present in some revision of interest to some place where Pelican can pick them up. With a "normal" (non-bare) Git repository you get this sort of for free: by means of having the work tree naturally coupled to the repository itself. But that's not required for having your files checked out. 90% of random HOWTOs you're able to google using "git+web+deployment" explain exactly this scenario: there's only a bare repository on the target server, and the files from the tip commit among those just pushed get checked out to some arbitrary directory. Most of the time this is done via environment variables, namely, GIT_DIR, GIT_WORK_TREE and GIT_INDEX_FILE environment variables. POSIX shell pseudocode for a post-receive hook: ---8<--- #!/bin/sh set -e -u GIT_DIR=/path/to/your/repo/on/the/server GIT_WORK_TREE=`mktemp -d /tmp/siteXXXXXXX` trap "rm -rf '$GIT_WORK_TREE'" TERM INT EXIT GIT_INDEX_FILE="$GIT_WORK_TREE/.gitindex" export GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE git read-tree master git checkout-tree -a pelican --srcdir="$GIT_WORK_TREE" --outdir /path/to/output/dir ---8<--- The script rolls like this: 1) Sets GIT_DIR to the path of your repo. 2) Creates a temporary directory for the files to be checked out. And immediately arranges for it to be removed when the script is terminated or exits. The name of this directory is assigned to GIT_WORK_TREE. 2) Make up GIT_INDEX_FILE variable pointing to a non-existing file under our artifical work tree. That's fine unless the name clashes with some existing file. 3) All these variables are then exported -- in order for the git programs called afterwards to see them. 4) The tip revision on "master" is read into the index. 5) The information from the index is checked out to the work tree. 6) Pelican runs. 7) The script exits and our temporary "work tree" gets deleted. Sure, there are other ways to do this. If your web site is huge, you can make your work tree persistent and use the correct keys to `git checkout-tree` to make it play well with the files already there. One last note on hooks: the hook you want to use is supposedly post-update, not post-receive. An error in the latter kind of hook aborts incorporating the history you've pushed while the former kind of hook only runs when the repository's object database is updated. Hence post-receive is for "linting" -- where you might decide to fail pushing for some reason, and post-update is for making use of the state just pushed. Now let's move on to the "deployment" phase. You have used the word "pushing" so it's unclear if you really mean using Git to sync whatever Pelican generates with your production server. While this is possible -- just turn Pelican's output directory into a regular Git repository and use `git add -A` + `git commit` there after Pelican finished running, -- IMO this needlessly complicates things and I'd better use rsync (or unison or whatever) or git-ftp [1]. 1. https://github.com/git-ftp/git-ftp -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
