Compare commits

..

1 Commits

Author SHA1 Message Date
b95e387622 POST-Deploying multiple jekyll sites at once 2018-12-06 01:12:00 -05:00

View File

@@ -22,38 +22,6 @@ On the server:
The server-side steps can be automated by utilizing git post-receive hooks (i.e. run immediately after the client initiates a push). The server-side steps can be automated by utilizing git post-receive hooks (i.e. run immediately after the client initiates a push).
Example:
~~~
#!/usr/bin/env bash
# post-receive hook to build and deploy jekyll sites
"/var/lib/git/gogs/gogs" hook --config='/var/lib/git/gogs/conf/app.ini' post-receive
# get repo name and set temp working git dir
GIT_REPO="$(pwd)"
TMP_GIT_CLONE="/tmp/${GIT_REPO##*/}"
# clone the bare repo into temp working dir
if [ ! -d "${TMP_GIT_CLONE}" ]; then
git clone "${GIT_REPO}" "${TMP_GIT_CLONE}"
cd "${TMP_GIT_CLONE}"
else
cd "${TMP_GIT_CLONE}"
git fetch --all
git reset --hard origin/master
git pull
fi
# install dependencies (requires Gemfile.lock to be created client side and added to git)
bundle install --deployment
# build and deploy
bundle exec jekyll build --destination /var/www/${GIT_REPO##*/}
exit 0
~~~
Although the process is straightforward, carrying out those steps repeatedly for multiple subdomains or websites can quickly become tedious. Although the process is straightforward, carrying out those steps repeatedly for multiple subdomains or websites can quickly become tedious.
For larger websites, I prefer using nested git repositories to simplify website deployment. This strategy used to be poorly supported in git and most IDEs, but recently they've gained wider support. A nested git repository works just as one would expect: a nested git repository (what I refer to as a subgit) can contain its own settings (for instance, pointing at upstream branches) while residing within a parent git repository that can be used to backup and deploy *en masse*. This is very helpful because the subgit can be managed independently from other portions of the website. For example, upstream changes can be merged into the subgit site without disturbing the state of the other git repositories. For larger websites, I prefer using nested git repositories to simplify website deployment. This strategy used to be poorly supported in git and most IDEs, but recently they've gained wider support. A nested git repository works just as one would expect: a nested git repository (what I refer to as a subgit) can contain its own settings (for instance, pointing at upstream branches) while residing within a parent git repository that can be used to backup and deploy *en masse*. This is very helpful because the subgit can be managed independently from other portions of the website. For example, upstream changes can be merged into the subgit site without disturbing the state of the other git repositories.
@@ -63,21 +31,19 @@ By combining the subgit strategy with some structured naming conventions it is p
Example: Example:
~~~ ~~~
#!/usr/bin/env bash #!/usr/bin/env bash
# post-receive hook to build and deploy jekyll sites
"/var/lib/git/gogs/gogs" hook --config='/var/lib/git/gogs/conf/app.ini' post-receive "/var/lib/git/gogs/gogs" hook --config='/var/lib/git/gogs/conf/app.ini' post-receive
GIT_REPO="$(pwd)" GIT_DIR="$(pwd)"
TMP_GIT_CLONE="/tmp/${GIT_REPO##*/}" TMP_GIT_DIR="/tmp/${GIT_DIR##*/}"
if [ ! -d "${TMP_GIT_CLONE}" ]; then if [ ! -d "${TMP_GIT_DIR}" ]; then
git clone "${GIT_REPO}" "${TMP_GIT_CLONE}" git clone "${GIT_DIR}" "${TMP_GIT_DIR}"
cd "${TMP_GIT_CLONE}" cd "${TMP_GIT_DIR}"
else else
cd "${TMP_GIT_CLONE}" cd "${TMP_GIT_DIR}"
unset GIT_DIR
git fetch --all git fetch --all
git reset --hard origin/master git reset --hard origin/master
git pull git pull
fi fi