I’ve used Hexo to build this site for two years. At the time, I kept my existing S3+Cloudfront hosting stack with a few minor tweaks. Yesterday I moved the whole thing over to GitHub pages.
I had a few reasons for doing this. One, I’m doing a project at work to roll out GitHub Campus and I want to get more familiar with the architecture. Two, for various reasons I want to be less dependent on the Amazon environment. I figured moving a static site from one architecture wouldn’t be a big deal, and I was right.
Hexo has a few deployment options. When I was using an S3 bucket I just rsynced the generated output, which won’t work here. The “right way” of handling the deployment would involve pushing source files and letting a GitHub Action build the site. My local environment is a little unclean–I have some uncommitted package dependencies–so that’s not a great option. I can however use the one-command deployment option with hexo-deployer-git. Per Hexo’s documentation, you add this to _config.yml
:
1 | deploy: |
You then run two commands:
hexo clean
hexo deploy
It’s important to run both commands. This approach creates a clone of the GitHub repository in a new .deploy_git
directory in the root of your project folder containing the generated static output, and then push to the remote directory. The clean command deletes and re-creates this directory, allowing the deploy command to push changes as a new commit. If you don’t do clean first, it’ll amend and force-push the last commit.
In terms of infrastructure, the site almost just worked after I cut over DNS to point at GitHub instead of Cloudfront. I needed to place a CNAME
file containing my custom subdomain inside the source/
directory; otherwise it was removed on every deployment. Next steps are to think about a better build pipeline, and whether GitHub is a reasonable choice for my gallery site.