I’m a ‘solo operator’ who doesn’t have much need for collaboration, or to roll out routine updates to a site’s codebase.
My usual Hugo workflow now is like this:
Build the site locally in my development directory
Use rsync to upload the build directory to the webroot on my remote VPS
The website works!
I’m somewhat familiar with the Continuous Integration/Continuous Development technologies out there now, though I haven’t played with any of them. What I know seems interesting, but I’m wondering if there’s any advantage to this kind of setup for my situation.
For example, I do make use of PostCSS and webpack/parcel, and that’s obviously a consideration for any server that has to build the site on the fly.
I don’t want to pick up a bazooka if the pop-gun still works, you know?
Given this, is there any good reason to make a move to CI/CD deployment? I do like the idea of pushing a commit to Git and having it automagically deploy to a live site – but, see above about the overkill issue.
I guess the bigger question I’m asking for here is, what’s a good use-case for CI/CD with Hugo?
Very opinionated advice and suggestions are welcome.
I schedule nearly all the blog posts I write, so ‘continuous’ deployment is what really makes this possible. That way ‘I’ can even update the website when I’m not at my computer or at home.
But if you don’t need that, then building your website locally and uploading that is a good approach too!
If you’re using github and its github pages, you can use something like this to rebuild your site every day and when you push a commit.
There’s a github training as well (using jekyll)
# .github/workflows/build-gh-pages.yml
name: github-pages
on:
push:
branches:
- master
schedule:
- cron: '0 0 * * *' # Every day at midnight UTC
jobs:
build-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1 # Checkout your repo
with:
submodules: true # Downloads the submodules too, common with hugo themes
- name: Setup Hugo
uses: peaceiris/actions-hugo@v2
with:
hugo-version: 'latest'
extended: true
- name: Build
run: hugo --minify
- name: Deploy
uses: peaceiris/actions-gh-pages@v3
with:
deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}
publish_dir: ./public
publish_branch: gh-pages # You'll need to setup this branch
Unfortunately how a periodic deploy looks is super dependent on what CI/CD provider you use. Everyone has their own format and configuration.
So if I may suggest I’d look first for the kind of service you want to use (GitHub actions, Gitlab, Azure, AWS, CircleCI, TravisCI, Netlify, …) that best first your workflow. And then look for examples of periodic deploys.
If you happen to choose CircleCI, this is the simplified workflow I use with CircleCI for my periodic deploys:
version: 2.1
workflows:
periodic_deploy:
triggers:
- schedule:
# Run at 5:00 UTC every Tuesday, Thursday, and Saturday
cron: "0 5 * * 2,4,6"
filters:
branches:
only: master
jobs:
- build
jobs:
build:
docker:
- image: cibuilds/hugo:0.65.3
steps:
- checkout
- run:
name: "Run Hugo"
command: hugo --minify
- run:
name: "Deploy Hugo"
command: |
hugo deploy --maxDeletes -1
This runs hugo --quiet before committing and cancels the commit if it fails. After the commit succeeds, it then rsyncs to your server.
This is a pretty simple example, and you could include additional steps on both sides like additional error checking (valid links?) for pre-commit and maybe downloading and syncing images post-commit.
