26 Jan, 2024 - About 3 minutes
GitHub Actions
Intro
In this article I will go through the steps to setup github actions to deploy hexo pages upon push requests into Github pages
Github Actions
GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triaging work the way you want.
Check the available documentation as there are several interesting examples
Hexo Setup
This tech notes site is maintained by Hexo a markdown blob framework.
The framework generates html static content based on Markdown articles an one needs carry the following steps to update content
- Create/Update Markdown content
- Execute
hexo generate
to generate content - Validate the pages with
hexo serve
- Deploy to your hosting service
hexo deploy
Setup
Include the following file .github/workflows/hexo-deploy.yml
on your hexo repo with the content:
name: Deploy |
- Replace
<GITHUB_USER>
with your user account and<GITHUB_EMAIL>
with your email address - Generate a new ssh-key with the command
ssh-keygen -t rsa -C "<GITHUB_EMAIL>"
making sure to use you email account - This step will generate 2 files a pub key which you need to configure on the destination repo as one allowed Deployment key
- And on the source repo you need to configure a secret where you will put the ssh-key
- Configure a personal token and register also as a secret on the source repository as ACCESS_TOKEN
That’s it you just need to start pushing changes
NOTE: This assumes the hexo source repository was already configured for the destination github pages account.
Multi repos
It is important to notice that you cannot assign the same deployment key for several repositories.
That is why I used a personal token, but there should be better alternatives.
Conclusion
Github Actions is a really powerful CI/CD tool and for this type of static generation content works rather well.
I had several issues regarding github submodules where the authentication was not passing. If you use the same approach for themes, you may endup on the same situation and using a token approach would be preferable
Also the ssh-keys being bounded by repo caused some initial confusion and there should be a better way to setup the authentication but I didn’t explore it in detail.
Also package-lock.json
are required for this to work and is advisable to have your source repo as private.
This workflow can certainly be improve like including tests and making sure that grammar validation is done as one example.