This post number 8 in the series Changelog. Find an overview of all posts in this series here.

You can find the predecessor post of the series here.

tl;dr

Two news:

  • Faster builds and less downloading for one build
  • Daily builds, enabling scheduled posts

Status Quo

The previous status was actually not too bad, but also not ideal. I had done the following:

  • All content management happens inside a Git Repo.
  • When I am done writing something, I commit and push the status to my Forgejo instance.
  • Forgejo runs an action that does the following:
    • Download the correct Hugo version
    • Also download and install rsync, which is used later on
    • Build the website
    • Do some verifications (mainly: do all links point somewhere?)
    • rsync the website to the correct space on my cloud server that it is served from

Issues with this concept

My main issue was that in my build process, I every time had to download the correct Hugo version, and also I had to install rsync manually - as these were not pre-installed in the base image.

Updates

Took me a bit to figure that out, but I actually already had created some custom Action-Images based on my own base image (which I will write about shortly). So let’s do the same thing once more! Not too hard, I think.

Nice side effect: Scheduled Posts

Already in the way of updating the Forgejo Actions definition, I also added a schedule: My blog now is automatically built every day in the morning. This has a relevant advantage:

By default, Hugo handles dates in posts: If I create a post and set a date in the future, Hugo does not render it on the website (unless explicitly told with --buildFuture).

Until now, the result of that was that I had to actually interact with my repo for publishing a new post - by pushing, or triggering an action manually.
Newly, I can just schedule posts and Hugo in combination with Forgejo Actions handles the rest for me!

Side effect: Build time

Not that building and deploying my blog took long - it was always below a minute for running the full action. But now with the new pre-built image (assuming that the image is already cached), the full build only takes about a tenth of the time it used previously. This is a cool side effect.

Problem: Versioning

One thing I have not yet solved is the question of versioning Hugo correctly.

Until now, I just had a file hugo-version.txt in my repo, which was read and parsed correctly by Renovate. With the downloading script that was run in the action, I always knew exactly which version to use.

Now with Hugo already baked into the image, I kind of have a problem here. The simpler part: The choice of version now happens outside the Blog repo. I could work around that.

The not so simple part is about Forgejo Actions. In my Action file, I defined runs-on: hugo. Renovate does not directly pick up on this line and does not do a versioning here - which is bad, if I choose to use a proper tag here instead of latest. Secondly, this hugo is hard-coded into the configuration of my Forgejo Runner, that this should use a specific image. I currently have no idea how I can fix this problem.