I’d guess hugo is unlikely to include built-in tools for deployment in exactly the way you have in mind. But you could use make and a Makefile. The make command executes a series of tasks specified in a Makefile. It can understand which tasks depend on others, and the order in which tasks have to occur. You can use make to e.g. invoke hugo to build your site, and then deploy it to your server using rsync or similar.
The Makefile I use to build and deploy my own hugo site is here. You would need to change both the obvious details, such as paths and server names, etc, but also likely the steps that generate and compress the CSS files and so on. A minimal build-and-deploy Makefile could be very simple. In any case here’s my example:
You could use something like https://zammu.in/hugo?invitation_code=RORYOK to build and deploy your website to Github Pages whenever you push your code to Github. Or if you want something on your own server, then you’ll have to setup a git hook to do the build and push in a post commit hook.
Hi - I just built such a thing over Christmas… Let me know what you think. It currently supports FTP over TLS only (which must cover 99.98% of low cost hosting accounts).
A few other points:
It tracks what has previously been sent and only sends diffs. Good if you have lots of media etc.
It optionally minifies HTML, CSS, js etc.
You will have to build from source. Let me know if that’s a problem and I’ll see if I can compile for you.
Read the instructions/warnings etc. I’ve tried to document it reasonably well. If there’s anything I’ve missed, let me know.
Yes, I know you can probably use Grunt etc to accomplish this and Kieran’s makefile approach will work fine, but for me nothing beats the beauty of a single, fast, tight executable. That’s why we love Hugo, right!
If your website host doesn’t support FTP, let me know. The code is organised to be able to plug in different deployment methods with relative ease.
Currently the password is held in the config file. Again, if you feel uneasy with that, let me know. It’s easy enough to move it to a command-line flag.
I was thinking about taking a slightly different approach and have been laying some of the foundation for that approach.
Permit me to outline my approach in hopes that it may inspire you further…
My approach would be to add this feature directly to Hugo.
Hugo deploy/publish <destination>
deploy would build it locally and then synchronize it to the destination.
It would use afero & fsync to do this. Hugo already uses them in a lot of places so leveraging them further makes a lot of sense. They also have the benefit of being completely cross platform.
A lot of work has been done as of late on Afero and it’s maturing quickly. We would need to add a backend for the different types of places we would want to support (sFTP, SSH, S3, Zip, etc).
Given the work you’ve already done, I imagine porting sftp to the afero backend would be straightforward enough.
Lastly the destinations would be defined in the config file. Different fields would be used by the various different types.
Does that make sense?
I think it would be great to have you adding this directly to Hugo so all users can benefit from it. Of course you are welcome to keep it as in independent binary, but I think the experience would be much cleaner and consequently the impact much broader if it was together.
Another note, If you are using viper for the config then it would be trivial to support passing secure information via ENV variables … eg HOST__PASSWORD=123456