Automated Deployment with Circle CI + Hugo

This just went out for our Frontend Friday and it seemed like something that is interesting for Hugo users.
We’re looking at Automated Deployment with Circle CI + Hugo in this article. We use CircleCI with Forestry.io every day and found it to be essential for our daily operations.

DJ walks us through why it is important for static sites to have a CI/CD implementation and how to implement one with a quick tutorial using CircleCI + Hugo. Let’s Build :hammer: Test :computer: Deploy :rocket:

Feedback and comments always welcome

3 Likes

Good article! Although it does rebuild Hugo with each commit to the master branch. Is it also possible with CircleCI (or a similar tool) to rebuild Hugo at a specific day of the week at a certain time? In my case I only want to rebuild Hugo then, and not with each deploy. Thanks for any insights. :slight_smile:

@Jura was thinking about getting Circle CI running too.

The answer is apparently yes: https://support.circleci.com/hc/en-us/articles/115015481128-Scheduling-jobs-cron-for-builds-

Also:

I guess if the default is to build when committing to master, then just build in a dev branch, and merge it to master to trigger the build. Not sure; have not tested yet.

1 Like

I use Gitlab. Please look here Scheduling Pipelines
The pipelines schedule runs pipelines in the future, repeatedly, for specific branches or tags. Those scheduled pipelines will inherit limited project access based on their associated user.

1 Like

Thanks for the links Rick and Joerg. :slight_smile:

From a few tests I did with CircleCI since posting here, I found it quite overwhelming. So I’m doubting jumping full in, also because their docs are written for people with a different experience/background than me. But perhaps if time frees up. :slight_smile:

@Jura I set up Circle CI today and it’s going well so far (really nicely engineered and “just works”, and big thanks to @FelicianoTech and Forestry.io for the tutorials).

I’m hosting on S3 and Cloudfront so the below config file reflects that, but you can deploy where you need to. The site I’m building is a “multihost” configuration, so the output folder gets language subfolders, which you then use to publish. You just need to make sure your paths are right in the config.

Also, a problem I still have not licked is, because I’m using Cloudfront CDN, but don’t want to invalidate all files every publish as it kind of defeats the purpose. I’m invalidating some generic files that often get updated on the deploy, and, then I use a script from my laptop to invalidate the specific URLs that got updated. It’s just a zsh function:

aws cloudfront create-invalidation --distribution-id THISONE --paths "/$1/*"
aws cloudfront create-invalidation --distribution-id THATONE --paths "/$1/*"
1 Like