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.
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.
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
Additional question (bit off-topic) : what sort of unit test do you run for your hugo projects ?
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 :).
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.
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.
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
