As I mentioned in my First Post, when I originally set this blog up I wrote a small shell script to rsync the static build of the blog to my web host. This works great, but it does mean multiple steps to get the blog published and persisted in source control. Enter Github Actions.
GitHub Actions are in the vein of capabilities provided by Drone, Jenkins, Travis, Azure Devops, and other CI/CD toolsets. I’m pretty familiar with Drone, having done a lot of Drone-based automation in conjunction with Ansible (probably several posts worth of stuff there), and if you’ve used Drone then Github Actions will be pretty familiar. In short, for those not familiar, you create a workflow definition for tasks to execute when certain events occur within your GitHub repo, such as a branch commit or a release tag. These workflows can take advantage of pre-built actions or simply execute shell commands to accomplish desired tasks. You can execute these workflows inside a Linux, Windows, or Mac container image, or provide your own container image. Super handy.
Fortunately, all the parts I need to build and publish the blog are available off-the-shelf. For the Hugo build portion, I’m using the hugo-setup action from peaceiris. This action installs Hugo in the container image and allows you to call the build process with whatever options you desire. Once the static files are built, I use the ssh-deploy action from easingthemes.
My workflow is now one step simpler. I iterate on new blog posts locally until I’m satisfied with the content, then just commit the changes to my GitHub repo. GitHub Actions takes care of the rest and updates the live site. Easy peasy, with the added benefit that I know that my content is persisted to source control before it goes live.
A couple of thoughts about these tools: it does cause me a slight pause to take these tools at face value and just pull them into my deployment process, especially since I’m entrusting an SSH private key to the ssh-deploy component. I’ve put an item into my mental backlog to pull the latest versions of each and scan through the code for my own sanity’s sake. If I do that and pin my workflow to those specific versions I’ll at least have some confidence that I’m not opening myself up to exploit. For my purposes the risk isn’t very great, but if you’re using these tools for more important stuff, do your diligence.
Comments