Automated Hugo deployments anywhere using Wercker

Today I created a Wercker step for building a Hugo site.

The details can be found on the article I wrote about it, but in summary it comes down to the ability to easily automate the deployments of your Hugo site using Wercker.

You might not be familiar with Wercker or why you would want to use this. In essence it’s a tool that will check your GitHub or Bitbucket repository for changes, and then run actions (steps in Wercker terms) against that code. This is further separated into two types of steps, build and deploy steps.

What I have done is create a build step for generating the static site. The end result of this is that I only need to push up a new post to my GitHub account and the deployment will then happen automatically. This means I am not limited to my computer for updating my site and that a lot of manual work is taken away from me.

Let me just provide an example of the configuration needed for this to show it’s not scary at all. This configuration is used by one of my sites for deploying to GitHub Pages, and I never needed to do create the git workflow mentioned in the official Hugo GitHub pages tutorial.

box: wercker/default
build:
  steps:
    - arjen/hugo-build:
        version: 0.12
deploy:
  steps:
    - lukevivier/gh-pages@0.2.1:
        token: $GIT_TOKEN
        domain: www.arjen.eu
        basedir: public

I’m posting this here in the hope that it will make life easier for someone other than me, but let me know if you have any questions.

10 Likes

That’s awesome. How would you feel about adding this, maybe fleshed out a tiny bit more, as its own tutorial that can get published to the docs?

Of course, no problem at all.
I’m glad people like it and want to use it, so I’ll create a pull request for it in the next couple of days.

Very interesting.

My guess the answer is no, but: Is it also possible to schedule builds n times a day? (to handle future posts in Hugo).

This is sensation @ArjenSchwarz: thanks for making it available. I don’t quite comprehend it yet, but I’ll look into more ASAP.

I see “we” can proudly claim it as an Aussie invention too, that’s even better.

As far as I know, Wercker doesn’t support that. It is an interesting question though, and even outside of Hugo I can see use cases for that kind of action. I’m going to have a look at it at some point, and at the very least contact the people at Wercker for a feature request.

As requested I’m working on a more clear tutorial which will include how to use Wercker, so hopefully once I’ve done that it will be a bit clearer on how this might be something you can use.

An extensive tutorial is now available in the docs at http://gohugo.io/tutorials/automated-deployments/

4 Likes

So far I have been using dploy.io with a lot of happiness. I am pushing my public folder to a basic ftp. On my repository I have many sites, and a single account on Dploy allos me to push different projects for free whenever I git push.
I think it’s pretty similar to Werker (and I prefer a tool named dploy for deployment :-D).

Anyone ever tested both apps and have a preference for Werker vs Dploy ?

There are other tools too, so if anyone has any feedback about them…

@tanzaho I haven’t played around with Dploy yet, but I definitely intend to do so now.

Without trying but only looking at the site, I suspect that the main difference between the two is that Dploy only does deployments while Wercker can do a lot of steps before that as well. Using the step I built for example it can generate the static site so you don’t need to do that manually, but you can also run unit tests, compile code, minify assets, etc.
Basically it looks like Dploy is a Continuous Deployment tool, while Wercker also does Continuous Integration. Both tools have their use cases, and as always it depends on your own workflow which would suit you better. Still, I wasn’t aware of Dploy before so I’ve now got a new tool to try out so thanks for that :).

Hi Arjen, indeed, with Dploy I need to manually run the static site generation locally, then create a new commit just for that each time. For the moment it’s not too much pain, but I can understand that for bigger projects, I might feel a bit annoyed.

When I’ll be back home I’ll give a go to your method :slight_smile:

Additional question (bit off-topic) : what sort of unit test do you run for your hugo projects ?

Are they like 404 checkers (for internal links, media, etc.) ?
Do you check that some menu has the correct amount of links ?

At the moment I don’t have any unit tests running for my Hugo sites, and I used that more as an example of what is possible. I trust the build itself enough that I don’t see the need for checks concerning the content, although you’re probably correct that it might be useful for static files.

But I don’t have that yet. Probably once I put more than just some basic Javascript in there I will want to test that, but my next step for these sites is probably going to be setting up a build pipeline for the assets. Maybe using Gulp as I haven’t used that before. That will be fairly simple stuff though, parsing and minifying javascript and css/sass files as well as some thumbnail generating for images. Now that I’ve got the basic stuff out of the way for them it’s time to play with the sites a bit more :).

1 Like

I followed the tutorial, but I am getting following error when trying to build in Wercker —

CRITICAL: 2015/04/28 No source directory found, expecting to find it at /pipeline/build/content

Can you please check if anything needs to be changed? This happens right after hugo file is downloaded. Below are last few steps –

$ source "$WERCKER_STEP_ROOT/run.sh" ..
...
...
2015-04-28 14:45:37 (51.4 MB/s) - `/wercker/steps/arjen/hugo-build/1.2.0/hugo_0.13_linux_amd64.tar.gz' saved [3876185/3876185]

CRITICAL: 2015/04/28 No source directory found, expecting to find it at /pipeline/build/content

Hello @pdholakia, that’s a weird problem. Do you happen to have your project somewhere I can have a look at it to see if I can spot any problems?

Thanks for replying, I deleted project thinking something went wrong. I will try it again over weekend to go over steps again to see if I missed anything.

@ArjenSchwarz the link to the application, in the tutorial, returns:

Application not found

Hi @fedelibre thanks for pointing that out.
I will try to submit an update to the tutorial this weekend, also in order to take into account some changes that Wercker has gone through since I wrote it the first time. In the meantime, you can see the application here and this is another example application that makes use of Wercker’s new infrastructure.

I love that tutorial on deploying Hugo with Wercker, so thanks for making it Arjen.

Does someone perhaps deploy their Hugo site to Amazon S3 with Wercker? If so, how do you set the cache-control HTTP headers for the different types of files with the s3sync build?

So far I’ve had success with

opts: --add-header=Cache-Control:max-age=604800

added to the deploy step, but I haven’t succeeded with more elaborate (customised) headers. Any ideas are more than welcome.

Hello @ArjenSchwarz,

I am trying this and I get an error message in the build phase.

zip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
/pipeline/hugo-build-4563b3fd-8359-4563-bf82-cd60193a9fc9/run.sh: line 32: /pipeline/hugo-build-4563b3fd-8359-4563-      bf82-cd60193a9fc9/hugo_false_linux_amd64/hugo_false_linux_amd64: No such file or directory 

I am using this wercker.yml:

box: debian
build:
  steps:
    - arjen/hugo-build:
        version: 0.14
        theme: hugo-creative-theme

deploy:
  steps:
    - lukevivier/gh-pages@0.2.1:
        token: $GIT_TOKEN
        domain: www.castillosings.com
        basedir: public

I tried the build step first as per the tutorial first and ended adding the depoy step afterwards. The error stays the same.

Any help would be greatly appreciated. As is your tutorial BTW.