Improved deployment of my Hugo site

This post is currently in an idea stage. It is a draft, sort of - but I put it out here as inspiration for you. And for me. Maybe I will actually fix it up now that it is here? Maybe not?

Improving how I build and upload my Hugo website was not a big problem. It wasn’t complicated, but it was manual and tedious. Me still working off of a Windows machine and the website being hosted on a linux server. My process was as following:

1. Write stuff (then commit and push for posterity) - and no, I still do not deploy from a pipeline on a cloud thing.
2. Run hugo to generate all the stuff
3. Zip the public folder - well tar the public folder, actually, and then copy it to the server with scp.
4. Then I ssh’d into the server, deleting the old files and putting the new set into the same folder.

This would have sounded much more tedious if I broke it up even more, but it is still bad enough. Maybe this was why I haven’t updated or written as much as I wanted? I can tell myself that and it will be a lie, but still - it didn’t help.

What my deploy pipeline has ended up with is as follows. In time, this post might/should end up in a how-to, and all these confessions and thoughts will be lost. Oh, well.

1. I still write stuff. Like this post. I will commit and push it, just as a backup. The published date will be what is in the frontmatter (metadata in this file) - the last updated date will be the git commit time, as seen in my last modified how-to post.
2. I still run hugo (or hugo --minify) to generate the actual html from the markdown files. Here I probably could have set it up to actually do all the following stuff as a result of doing hugo deploy - but hey, I’m on Windows.
3. Here I go into bash - which is for me Ubuntu in Windows sub-system for Linux (or wsl for short)
4. And I run a script named… deploy.sh - whoo! My webpage is where it is supposed, it still took 4 steps, and you are still not informed. Worst how-to ever.

How to move all the files

I move all the files using rsync - with the right options it connects to the server I want to upload to, moves to the correct folder, uploads files that have been changes, deletes files that have been removed and leaves everything else alone. No big magic, all known and existing for 30 years or so.

I’ve known it was possible, I just haven’t done anything about it. Firstly, I’m on Windows at home. Secondly, it involves deleting files on the other end - and I do not want to point it at the wrong place, losing stuff. For the first one, the fix is to do the work on a Linux system - either push the sources somewhere and run hugo there, or have another step done on wsl.

How not to delete the wrong files

To avoid having to type in a password when connecting to a remote server, you set up a key-pair. One bit is private, keep it safe. The other is the public one - share it with everyone who need it. If you use the private one to encrypt - anyone with the public bit can trust it was you who did it.

This is used over ssh, and by extension, over rsync when communicating. This solves nothing by itself, but by making a new key for just uploading my hugo site, I can make sure not to break anything.

To allow a key to be used, you put the public bit on the server in a file called ~/.ssh/authorized_keys - now it can be used. This file also allow you to limit what the key can be used for, so here I created a small script that checks:

1. I used rsync targeting the specific folder
2. I do not try to move out of that path or do other bad stuff If any of these fails, I’m not allowed to use the key.

On my own computer, I call rsync with the option -e "ssh -i $DEPLOY_SSH_KEY" - ensuring I log in using the key that only can rsync to the correct folder.

But how do this constitute a “how-to guide”

It doesn’t. Sorry. While it works for me right now, I need to clean up and verify that there isn’t any glaring holes in my reasoning. Tell me if you want to know more, or any specifics. Maybe on mastodon. Or email.