Re: [git-users] Deploying a static website to local and production servers
On Tue, 2 Jun 2015 18:09:25 -0700 (PDT) Márcio Moreira wrote: > I am sorry I forgot to say previously that Pelican runs on the > collaborators laptops. The versioned folder already includes source, > output, and other sub-folders and files. The workflow: our > collaborator will edit the source files; run pelican to generate the > output files; verify the output files using a browser; and, after > confirm everything is OK, he/she will commit the changes and push > them to our local server (origin). > > We need to version control and store on the local server the files > already available on the laptops. > > What we are looking for is a way to copy one of the versioned > sub-folders (named output) from local server (origin) to another > server (webhosting), making use of post-update, when origin is > updated. [...] OK, that actually makes things simpler, not harder (though I admit I don't understand why you have decided to keep the results produced by Pelican in the same repo). The hook would basically populate the work tree as before but instead of running Pelican on the populated work tree, you'd just need to sync the contents of a single directory in that work tree to the remote server. The ways to transfer it remain the same. -- 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.
Re: [git-users] Deploying a static website to local and production servers
Konstantin, Thank you for your answer. I am now studying all you said. I am sorry I forgot to say previously that Pelican runs on the collaborators laptops. The versioned folder already includes source, output, and other sub-folders and files. The workflow: our collaborator will edit the source files; run pelican to generate the output files; verify the output files using a browser; and, after confirm everything is OK, he/she will commit the changes and push them to our local server (origin). We need to version control and store on the local server the files already available on the laptops. What we are looking for is a way to copy one of the versioned sub-folders (named output) from local server (origin) to another server (webhosting), making use of post-update, when origin is updated. Git , version control, and english, are still a bit mysterious to me and sometimes I can´t find the words. I hope you understand. Greetings, Marcio Em terça-feira, 2 de junho de 2015 12:09:58 UTC-3, Konstantin Khomoutov escreveu: > > On Tue, 2 Jun 2015 07:26:54 -0700 (PDT) > Márcio Moreira > 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/siteXXX` > 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 l
Re: [git-users] Deploying a static website to local and production servers
On Tue, 2 Jun 2015 18:09:52 +0300 Konstantin Khomoutov wrote: (Cc'd Nick, who recently asked a question about GIT_DIR.) [...] > 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. [...] To be more clear, these environment variables are documented in the git(1) manual page -- that is, the manual of the "root" git command. You can get it by running `git help git`. A good informal introduction to this stuff is [1]. 1. https://git-scm.com/blog/2010/04/11/environment.html -- 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.
Re: [git-users] Deploying a static website to local and production servers
On Tue, 2 Jun 2015 07:26:54 -0700 (PDT) Márcio Moreira 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/siteXXX` 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.
[git-users] Deploying a static website to local and production servers
Hello, 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? Anyway, every advice is welcome. Thank you, Marcio -- 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.
