1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
---
layout: post
title: Auto-deploying my blog
date: 2020-01-04 19:10 +0100
language: en
categories: [meta]
tags: [meta]
---
So, after fiddling around for several hours, I finally managed to auto-deploy my
[Jekyll](https://jekyllrb.com/) blog from Git.
The main difficulty was that the blog is hosted on a standard shared web hoster,
whereas the actual Jekyll blog content is hosted in a Git repository on a VPS.
Of course I could've moved the blog, which would've made the whole ordeal
easier. But where's the fun in that? So, after considering
[Weex](http://weex.sourceforge.net/) for a moment, I reconsidered and decided to
use lftp's mirroring mode instead. A strong must was the support of FTPS, by the
way. My shared hoster does allow SSH access, but I can't (afaik) restrict access
to specific directories, and I wanted to minimize impact *if*, god forbid, the
credentials get in the wrong hands. With an FTP account, I could restrict access
to a specific subdirectory, however.
My setup also uses [buildbot](https://buildbot.net/) as "CI/CD" server.
It was a lot of fiddling around with the following problems:
- I use [RVM](https://rvm.io) to install Ruby (required for Jekyll) and need to
source the environment first (at least I think so), so I have to use a shell
command of
`["bash", "-c", "source ~/bash_profile && bundle install && <jekyll build>"]`
- I needed to add the `haltOnFailure=True` argument to all steps (why isn't this
the default?), to make sure I don't end up mirroring an empty directory.
- I needed to create a separate worker instead of using `LocalWorker`, because
only this way I could specify the umask of the worker files. The default is
secure (077), which leads to the umasks being mirrored to the server by lftp,
resulting in an inaccessible blog. (I don't quite get the lftp documentation
about the `--no-umask` flag - what EXACTLY does it do, i.e. which umask does
it use).
During my fiddling, I saw someone mentioning [Drone](https://drone.io/), which
might be worth a closer look sometime in the future. From what I got it supports
the pipeline being set up in the repository itself, which means I wouldn't have
to fumble around with the buildbot config were I to change the "build" procedure
in the future.
Also it supports docker. If I were to use a ruby docker image, I wouldn't have
this weirdness with sourcing the `.bash_profile`. But since I'm using the
cheapest VPS with the lowest RAM + disk space possible, I'm quite reluctant of
that option.
|
