3.1 KiB
+++ date = "2018-08-23" tags = ["hugo","gitlab"] title = "hugoとgitlab ciのpipeline schedulesで自動更新する" slug = "hugo" +++
静的サイトジェネレーターは、それぞれに特徴的でした。昔、hugoは将来の日付で書かれた記事も素直にbuildしていた気がしますが、最近では、buildするコンピュータからtimeを取得して、将来の日付の記事をbuildしないようになった気がします。
ちなみに、middlemanでは、昔からこの挙動でした。つまり、将来の日付はbuildしないという挙動です。コードの書き方によって設定できるとかがあるかもしれませんが、自分が触っている限りでは、そんな感じでした。
で、結構昔からhugoを使っていて、そんなもんだったわけですから、自動更新の仕組みを作るにしても、相当にめんどくさかった。
具体的には、/content/postにmdを置くわけですが、それを置く時期をこちらで処理しなければならなかったのと、後は、定期にbuild, deployをciで実行することをやっていました。
ただ、こちらもできればserver lessにしたいわけなので、docker imageを作成して、それをdocker hub(private)に上げた後、travis-ciでcron jobsでそのdocker imageをpull, runし、pageのrepoにpushして、そこでgitlab-ciを発火するように設定していました。めんどくさすぎますが、仕組みとしては単純に役割が決まっています。
docker image : gitlab-push
travis-ci : cron, docker-run
gitlab-ci : page build, deploy
しかし、gitlab-ciもかなり便利になったもので、cronにあたるpipeline schedulesが実装されたこともあって、travis-ci(cron-jobs)が不要になりました。
また、hugoもsrcから将来の日付の記事をbuildしないようになったため?わざわざdocker-imageでその日のものをcontent/postに置く処理が不要になり、将来の日付の記事を含めたすべてを/content/postに置いていても問題なくなりました。
とは言え、srcを公開している場合、この手法は使えません。また、docker-imageで合わせて処理をしていたjsonを作成してpushする処理もgitlab-ciでやることになるか、もしくは面倒なので諦めるかということになりそうではありますが、とにかく便利になったなあと感じています。
今後は、hugo+gitlabでブログをやるとしても、自動更新の点では、他のサービスに比べて遥かに楽にできるようになるでしょうね。これまではいろいろと組み合わせてやっていましたが、gitlab-ciだけで事足りるようになってきた感じです。
ただ、まとめて書くにしても、何か書くことって、それ自体、結構つらかったりしますからね。書くこともそんなありませんし。その点では難しいかもしれませんね。
おわり。