There has been some big developments in my life this year so far of which I won’t get into on this blog (for now) but as a result, I haven’t been doing much, if any, web related development.

However, due to a desire to do something “meaningful” with my time instead of lying around in bed daily, I decided to look into updating this blog again. Or more exactly, set things up so that adding a new blog post will automatically regenerate my blog contents and post it to this site. Yes, there are various well-documented solutions out there that post to various third-party services with decent CDN that now provide static pages hosting such as Netlify, GitHub, GitLab etc. But the reality is I have my own server and would like to keep my data on my own server.

Now I’ve played around with a decent solution sometime last year, with a small Hugo powered static site by setting up a GitLab Runner on my server to run Docker that would generate the content and then deploy to Gitlab Pages. As I recall, it wasn’t a terribly difficult process and I was quite impressive by its results – and it still works today!

So I decided to duplicate the same setup for this blog and discovered that when it comes to publishing content to your own server, even with the runner running on the same machine, it was no easy task. A list of issues that I encountered included:

  • Checking out Git submodules: The setup I have is that my “blog” is really my theme together with a base content folder which includes my About page. My actual blog entries (musings) are stored in a seperate repository as I tend to update those entries more frequently and wanted to keep it distinct from what I consider less frequently updated “static” content. This would also enable me to switch themes while keeping my content separately managed. As it turns out, because the reference to the submodule is a direct URL, it would require credentials to check out. I’m not a paying customer of GitLab so I couldn’t obtain deploy tokens (which seems to be the right solution to use according to their documentation) so I ended up using the personal access tokens. Obviously this is a big security risk but honestly, at this point in time, I’m more interested in building out a pipeline that works and then worry about refining things later on.

  • Since I was repurposing the .gitlab-ci.yml from the previous project which uses the Hugo Docker image directly, I forgot that it was technically just a Hugo binary that does not have SSH or various Linux system calls available for use. That always slips my mind and to be honest, I don’t feel like building my own Docker image and I haven’t really looked into what base image they are using for it. At this point, I’ll worry about deploy things later. Why? Because despite being an “official & latest” image, its generated results (as currently published on GitLab Pages) looks completely different from what gets generated locally on my machine which is so puzzling (and brings back nightmares) and is more concerning that trying to get it published to the correct deployment point.

That’s sort of where I’m at right now, and I think because of the dated theme templates, I have to pivot to actually revising and revamping my outdated theme before attempting to continue on this project of automating the deployment of my blog (of which I’m starting to consider just setting up a hidden webhook to simplify things!).