Hugoのbuildからアップロードまでをgitで半自動化。Windows10とエックスサーバー
私は 主に hugo でサイトを作成しているのですが、build したあとにアップロードをするのがめんどくさいと感じていました。
これがあるばっかりに更新をちょっとサボりがちになったりすこともしばしば。
とりあえず下書きでいっか、で止まってしまうのです。FTPのソフト(ffftpやfilezillaなど)を立ち上げていちいちポチポチするのがめんどくさいからです。
なので git の hooks を使い、build → アップロード
までの流れをズバッとひとまとまりにしました。
なぜ git を使うとできるのかを説明しろと言われても無理ですが、とにかくできるのです。
どうやら昔からある有名な方法らしいですが、私にとっては難しかったです。つまり忘れそうです。記録しておきます。
あくまでも私の環境下での作業工程なのであまり参考にならないかもしれません。
- Windows10
- Hugo
- git 導入済み(git for windows)
- エックスサーバー(git 設定済み、ssh接続設定済み )
これで build → アップロードを半自動化します。
エックスサーバーはデフォルトで git が使えますので設定不要。バージョンが古いのですが、とりあえず動いたので今回はそのまま。不具合が出たら更新を考えます。
SSH接続するまでは公式はじめ色々なサイトで詳しく解説されていますので端折ります。秘密鍵など色々難しいことが多く長くなるので私の技量ではまとめきれません。
そして何よりここから先のことがどこを見てもあまり意味がわからなかったので記録しておきたいのです。
目次
結局の所なにをするのか
- レンタルサーバーの公開ディレクトリに git のベアリポジトリを作成
- レンタルサーバーの非公開ディレクトリに git のノンベアリポジトリを作成
- ローカル(自分のパソコン)に git のベアリポジトリを作成
そして、
- ローカルで build してから、 2.のノンベアリポジトリへ push。変更を反映させる
- ノンベアリポジトリの変更を受けて、サーバーの公開ディレクトリのベアリポジトリは勝手に更新される
ということが可能になります。ここまでは準備のようなものです。
- Hugo の build から git の push までを一発で出来るスクリプトを作成
さっさと6をやりたいんだけど、そのためには1~5までが必要、という感じでした。
ベアリポジトリとかノンベアリポジトリって何?という話は以下のサイトが参考になりました。
ベアリポジトリとノンベアリポジトリ:理論編〜GitでWordpressのテーマを管理
wordpressだろうがなんだろうが基本は一緒だと思うので、たぶん読むとわかります。
エックスサーバー側の準備
以下のような名前であるとして進めます。
- サーバーID: マイサーバー
- 独自ドメイン名: サンプル.com
何かしらの方法でSSH接続し、お手持ちの bash なりコマンドプロンプトなりで黙々とコマンドを打っていきます。
SSH接続できない、あるいはなにそれ?という方は以下のページなどを参考にして下さい。
エックスサーバー上の公開ディレクトリでノンベアリポジトリ作成
エックスサーバー上の ドメイン名/public_html
以下の全てのファイルを git で管理している状態にする。
まずはエックスサーバーにSSHで接続して サンプル.com
のpublic_html
に移動。
$
より後ろが自分で打つコマンド。
[マイサーバー@sv9999] $ cd サンプル.com/public_html
移動後、
[マイサーバー@sv9999 サンプル.com/public_html] $ git init
[マイサーバー@sv9999 サンプル.com/public_html] $ git add .
[マイサーバー@sv9999 サンプル.com/public_html] $ git commit -m "first-commit"
エックスサーバー上の非公開ディレクトリでベアリポジトリ作成
[マイサーバー@sv9999 サンプル.com/public_html] $ cd ~/サンプル.com
[マイサーバー@sv9999 サンプル.com] $ git clone --bare --shared ~/サンプル.com/public_html public
Cloning into bare repository 'public'...
done.
これでpublic_html
で作成した「公開ディレクトリ」のベアリポジトリが出来たことになります。
ベアリポジトリの名前ですが、本当はサンプル.com.git
のようにするのが慣習らしいです。
ですが、今回はHugoのpublicディレクトリを使うので初めからこの形のほうが楽という理由でこうしました。
エックスサーバー上で動くプログラム、post-receiveの作成
「非公開ディレクトリのベアリポジトリ」が更新されたらその内容を「公開ディレクトリ」に反映させる、というプログラムを先程作成した public
ディレクトリの中にあるhook
ディレクトリの中に作成します。
[マイサーバー@sv9999 サンプル.com] $ cd ~/サンプル.com/public/hooks
[マイサーバー@sv9999 サンプル.com/public/hooks] $ vi post-receive
2行目はvi
というテキストエディタでpost-receive
というファイルを作成する、という意味ですが別にファイルが作成できればなんでもかまいません。しかし、サーバー上でのファイル編集はvi
でやるのが一般的な模様。
使い方はググればバンバン出てきます。
post-receive
#!/bin/bash
cd ~/サンプル.com/public_html
git --git-dir=.git pull ~/サンプル.com/public master
作成したら、実行権限を付与。
[マイサーバー@sv9999 サンプル.com/public/hooks] $ chmod +x post-receive
これにてエックスサーバーでやることは終了です。
ローカル(自分のパソコン)の準備
Hugo の public
以下の全てのファイルを git で管理
自分のパソコンのHugoで作成しているサイトのディレクトリで作業します。
public
ディレクトリを削除。- エックスサーバー上に作成したベアリポジトリを git clone
今後は先程作ったエックスサーバー上の新public
を使うので今ある旧public
は不要です。失敗したら困るので一応バックアップを取っておいたほうが無難(hugo buildで一瞬で作れてしまいますが)。
git clone の前に準備
SSH接続用に作成してあるはずの.ssh
ディレクトリでconfigを以下のようにしておくと便利です。
コマンドプロンプトなどからssh マイサーバー1号
と打てばサクッとエックスサーバーにSSH接続できます。
~/.ssh/configに以下を記述
Host マイサーバー1号
HostName マイサーバー.xsrv.jp
Port 10022
User マイサーバー
IdentityFile ~/.ssh/id_rsa
ServerAliveInterval 60
エックスサーバー上に作成したベアリポジトリを git clone
[自分のパソコン hugo/自分のサイト] $ git clone マイサーバー1号:~/サンプル.com/public
または
[自分のパソコン hugo/自分のサイト] $ git remote add origin マイサーバー1号:~/サンプル.com/public
として、既にあるリポジトリに追加しても同じことになる、らしいです。が、私は最初にこれを試して上手くいかずさまよいました。きっとどこかで記述を間違えていたのでしょう。検証はまた別なサイトの分でやることにします。
build から push まで一発でやるコマンド。.bashrc に記述
# git add, commit, push まで一度に行う
buildpush() {
hugo;
cd public;
# 全てステージに乗せる
git add -A;
# コミット対象のファイルを確認
git status;
read -p "Commit with this conent. OK? (y/N): " yesno
case "$yesno" in
# yes
[yY]*) read -p "Input Commit Message: " msg;
git commit -m "$msg";
CULLENT_BRANCH=`git rev-parse --abbrev-ref HEAD`;
git push origin ${CULLENT_BRANCH};;
# no
*) echo "Quit.";;
esac
cd ..
}
これで build から push まで 一気に流れで出来るようになります。
まとめ
参考サイト
ftpソフトを立ち上げて操作する手間を省きたかっただけなのですが、とても大変な長旅になりました。
特にSSH接続だとかサーバーの操作は何かミスったら取り返しがつかないことになるんじゃないかとかビビってしまうのですが、じっくりやればなんとかなるもんだと思い知りました。
世の中には色々便利そうなツールがたくさんあるようですが、自分の環境にピッタリハマるものは意外と少ないです。ツールに合わせて環境を変えるのも手だと思いますが、現在の状況に合った手法を探るのもそれはそれでいいことがあるんじゃないかと正当化してさようなら。
記事一覧へ戻る