Why?

It’s been over 7 years since I last posted on this blog, which had multiple reasons:

I was more in love with microblogging using Twitter (now X). After a change in management and some weird decisions, the platform no longer felt like home and whilst I found my place on mastodon, it never felt like an adequate replacement. After some more months and more questionable decisions, I finally decided to leave X after 13. years.
I was deeply involved in my professional career, and I still am, but I feel like this blog could be a better use of my free time.
I was using Pelican to host my blog and, over the years, lost access to the files (they’re probably still in a backup somewhere, but I couldn’t motivate myself to start digging) and I had a bad memory about the build pipeline being painfull, which didn’t add to my motivation.

Choosing the right tool for the job

I’ve had some experiences with jekyll, the websites of DENOG and Stuttgart-IX which I (Co-)maintain are both built using jekyll. Jekyll usually does serve its purpose, but equally, I’ve spent too much time chasing the right version and fixing the build pipeline. Also for both projects I’m working on, it’s awfully slow.

Meanwhile, some of the blogs I enjoy reading[1][2][3] are using hugo, so I decided to give it a try.

Hugo it is!

Migrating content

Sadly, I also lost the original Markdown files somewhere in my backup, and I couldn’t be bothered to find them again. Since I’ve only had 10 posts, I went with the easy, yet manual way. Copied the text from the HTML files, reformatted it and was done in 30mins. Am I proud of this approach? No. Did I hate every second of this manual labour? Yes. Do I regret not spending 5h to come up with a cool solution? Absolutely not! Sometimes simple and quick is better for a one-off, and I don’t really plan on repeating my mistake.

Choosing a theme

Hugo has a great variety of themes, after taking notepadium for a quick spin, I landed on papermod purely out of personal preference.

Build Pipeline

If you’ve made it here, you have heard my frustration with previous build pipelines of static site generators. To avoid this going forward, I’ve settled on github actions. Using git has, over the past 10 years, become more natural to me, and I like having pipelines do all the thinking for me.

I wrote a small github action to render the site and push it to a release branch: .github/workflows/build-release.yml

name: Build Site to release branch
on: [push]

jobs:
  build_and_deploy_hugo_site:
    runs-on: ubuntu-latest
    name: Build and deploy Hugo site

    steps:
    - name: Setup Hugo
      uses: peaceiris/actions-hugo@v2
      with:
        hugo-version: '0.143.0'

    - name: Checkout repo on source_branch
      uses: actions/checkout@v2
      with:
        submodules: 'recursive'
        fetch-depth: 0

    - name: Build site and push to release branch
      uses: aormsby/hugo-deploy-to-pages@v2.1
      id: build_step
      with:
        source_branch: 'main'
        release_branch: 'release'
        full_rebuild: true
        hugo_publish_directory: 'release' #rename public to circumvent gitignore

Deploying the release

I’ve checked out the release branch on my webserver, which I finally switched to and got free Let’sEncrypt cerfiticates as a result, to the release folder. Since logging in and issuing a git pull doesn’t feel like something I would enjoy doing, I’ve built a quick systemd service and timer: /etc/systemd/system/blog-pull.service:

[Unit]
Description=Pull Git Repository
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
WorkingDirectory=/var/www/blog.hackathon.de
ExecStart=/usr/bin/git pull

[Install]
WantedBy=multi-user.target

/etc/systemd/system/blog-pull.timer:

[Unit]
Description=Timer to Pull Git Repository Every Hour

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

After a systemctl daemon-reload I could enable the timer at boot systemctl enable blog-pull.timer and start it for the first time systemctl start blog-pull.timer.

Conclusion

This blog now has a new home and a nice pipeline to go with it, the old content is migrated and I can finally start filling it with content (which I’m most afraid of). So far, I’m really enjoyin hugo and the -N option that navigates to changed content file on live browser reload was a very nice quality of life feature during development. I like the outcome so far and am excited for what’s next.

Why?#

Choosing the right tool for the job#

Hugo it is!#

Migrating content#

Choosing a theme#

Build Pipeline#

Deploying the release#

Conclusion#