Testing out a new deployment system
This is a test, please don’t ignore! Or well, you can, but it’s only a quick one, all about how I’m trying to hack together some static-site publishing from my ipad.
What my previous static site deployment looked like:
- I’d write the new post into my repo.
- Commit and push it just for safety/backup.
- I’d manually rsync the build folder up to my vps
- Hey-presto, new site was live.
What’s happening here? Well to get this post onto my website the following steps must have happened:
- A Github Actions workflow has ran, based on a manual trigger or me pushing master.
- The runner has pulled this file (and any other markdown files in the right directory) and place them into the /posts folder in my hugo repo.
- The runner has done the same for any static content, recursing down into sub-folders to keep the right structure.
- The runner performs a
hugo buildand then archive’s the results. - The runner triggers an AWS remote shell command on my VPS.
- The VPS uses a token it has to download the bundle from github and then unpacks it to the right nginx path.
- Hey-presto, new post is live.
The main goal here was to enable me to “deploy” a static site using only ‘cloud-native’ tooling so that I can update it from any device that I have access from. I’m in the process of automating and improving how I’ve been hosting more traditional (read static & WordPress) websites over the past month or so, hopefully I’ll be able to write more posts soon about how I’m doing it. Heck I might even share the code/config I have if it’ll be useful for others.
Of course, if you’re not reading this, then it didn’t happen… so I must have broken something somehow 🤔 and that tree probably didn’t make a sound. But you are, and it did, so woop. Here’s a random image to both celebrate and prove that the static image stuff is working too!
