I’m not the most prolific writer in the best of times, and I’ve spent the past month doing many interesting and detailed things to Linux servers with my friend and BubbleSort co-wrangler Vic Hudson.
Rather than presenting this information to you as an excuse for my tardiness in publishing anything new, the takeaway here is that all this server poking and prodding has resulted in me having a new workflow for publishing to my sites, and that has resulted in me reworking my blog post publishing shortcut (and next, my podcast episode publishing shortcut).
Far from being more complex, my workflow is now simpler: all I have to do is parse the text of my blog post and make some text transformations that will make my post work when Hugo compiles it, choose a section, category, and some tags, and update my git repo and push that to GitHub.
The text transformations and the git repo commit and the GitHub push are all transparent to me, which is part of the beauty of automation. The lists of sections, categories, and tags that I am presented with to choose from are also created in ways that are transparent to me, and it’s quite beautiful, frankly.
Did you notice what my shortcut does NOT do?
My shortcut doesn’t upload any files or ssh to my server to recompile the site. It literally only processes the text, creates the final markdown file, and puts that in the correct place in my git repo for the site, along with any attached images. That’s it.
GitHub reaches out to my server and says “hey, you might want to do a pull because some things have changed”, and the server does! It pulls the repo for that site and compiles it.
I was a little hesitant about that workflow when Vic first brought it up. Two things occurred to me that I figured I should worry about: mistakes and security.
Mistakes can’t necessarily be avoided, but the good news is that pushing a fix is just as fast as pushing the mistake, and the site will get updated instantly. Also anything that is really onerous will cause the site not to compile anyway.
As for security, the server does most of the work on the repo pull from GitHub, and it receives minimal information and zero files for the trigger. I’ve also taken the extra step of making sure that the port it’s listening for GitHub messages is blocked for any IPs not in the GitHub IP block. It’s probably not insurmountable, but it will definitely eliminate positive scans and pokes and prods to that port.