Hugo CMS

[girish]

It's all on your PC/mac. But yes, we should make a guide at some point in our docs for such content.

[malvim]

Seems simple enough, I think I could take a stab at this. I've packaged a bunch of stuff for myself, but would be nice to have something "production-ready", with all the requirements, tests and stuff.

[A Former User]

Hugo would be great but I do agree that static site generators are an odd ask given that surfer or GitHub pages steps to use Hugo could be used to, as I like to say, “document the problem away”

[girish]

Yeah, I think if really want to package Hugo, it will need to essentially code a "workflow". Meaning, we can git push to the app or something (like GitHub pages app). Otherwise, there is nothing to package as such.

[A Former User]

Exactly. I’m struggling to think of a way to package Hugo where it wouldn’t just end up being GitHub pages or a lamp app where people manually upload their generated site.

[robi]

It's better coupled with a Front End app than can maybe aggregate content via RSS or other scripted automation, then generate the pages via Hugo/Jekyll/.../etc to wherever you need.

[fbartels]

My blog (served through the surfer app) is built with Hugo. I was briefly looking at modifying the Github pages app, but for me it was a bit strange that I then would also need to store the source repo for the homepage inside of the app (I already have Gitea for this).

I have now setup a ci flow with Drone (managing app running on Cloudron as well, agents running elsewhere). Only downside is that the surfer cli is quite slow for lots of small files, uploading my page currently takes 15 minutes.

[robi]

@fbartels can you rework the CI to tar first then untar in surfer? not sure tar is available inside the container.

[fbartels]

@robi yes, that is also how I am publishing another static app (Homer), but that would require breaking up the deploy process into individual commands (as opposed to the simple surfer put --token $SURFTOKEN --server blog.9wd.eu public/. /.

[robi]

Then surfer needs a pipelining upgrade for the transfer of files in one go.

From the shell we can pipe tar - over the network which could be as simple as that.

[nebulon]

I am about to finish a surfer sync <src> <dest> feature to be used in such pipelines to update the files. I hope that would work there then.

[fbartels]

thanks @nebulon. Not quite sure if it would help in my case, since the page is rebuilt in a clean environment each time, so while the content may be the same, at least timestamps will have changed.

[jdaviescoates]

@atrilahiji said in Hugo CMS:

“document the problem away”

Yes, I think this is probably the answer. If there was a good step by step guide for beginners as to how to get started with this static site stuff then people could just do it.

What I want is a nice self-hosted documentation site that people can "click to edit this page on GitLab/ Gitea/ Gogs" like lots of people already do GitHub pages and Github. or with Gitbook.

The impression I get is that this really shouldn't be that hard to do using Surfer together with one of the Git apps on Cloudron (and/ or GitHub Pages), but I'm still not really sure where to start

Perhaps I should spend less time on this forum and more time reading up about it all! Then I could help write the guide! that might happen eventually!

[nebulon]

@fbartels That is indeed true, I was thinking of adding checksum tests though, but for now the sync already helps to purge files on the remote end, which don't exist anymore in a new build. Of course if the pipeline is used to build artifacts or packages, then the old surfer put should be used to not purge the old ones

[fbartels]

@nebulon I noticed that in newer surfer version you added some parallelization for put requests. Upgrading surfer to the lastest version brought the deployment time down to four minutes.

[vjvanjungg]

@jdaviescoates check out my new guide https://forum.cloudron.io/topic/4042/beginner-s-guide-hugo-gitlab-ci-surfer hope it helps you get up and running.

[doodlemania2]

@vjvanjungg Very nicely done!

[timconsidine]

Sorry to revisit this old topic
Fully appreciate about static site generators building locally and push-publishing remotely.

But there’s an element to the discussion missing. In my case, I don’t want to be building locally. Then I am tied to a specific local device. It may not be to hand (and maybe too lazy to levitate posterior from sofa).

Yes, I could sync local configs between devices, but that’s not always smooth.

I would prefer to use a cloud resource to build and publish. If I am working in the terminal locally, no different to working in terminal remotely.
Yes, I could setup a remote deployment of a Linux desktop, use that to build and publish to eg Surfer. But why the duplication ? Seems more elegant and contained to be able to do it in one place.

I know this is contrary to the CI/CD bandwagon. But I see a lot of advantages, principally avoiding multiple component pieces.

[girish]

@timconsidine afaik, hugo is a CLI tool. One has to write a web application that you ask for - something which accepts git pushes or accepts uploads or monitors some git repo etc and then builds via hugo.

To be fair, this is what we did with GitHub Pages app . It runs jekyll and accepts git pushes (but only via http)

[timconsidine]

@girish hugo is CLI for building and outputting the built files.
Totally happy with building the site pages in terminal, rendering them in Hugo, using webserver to serve.
I just want to do it all in one container, without CI/CD, cloning repos, pushing files.
Maybe I will try a custom image based on Surfer.