Hugo CMS

[girish]

@gdeflaux You can use hugo with surfer to deploy already.

• Follow the hugo quick start:

    hugo new site quickstart
    cd quickstart
    git init
    git submodule add https://github.com/budparr/gohugo-theme-ananke.git     themes/ananke
    echo 'theme = "ananke"' >> config.toml
    hugo new posts/my-first-post.md
    hugo -D

• Then we just need to deploy public/ which contains the static pages. Install surfer on Cloudron. And then:

    npm install -g cloudron-surfer
    surfer login surfer.example.com
    surfer put public/ /

That's it!

[jdaviescoates]

@girish this sounds/ looks really easy, but for someone like me I'm still not really sure how to do it.

Even though I've run Linux since before Ubuntu existed (and Ubuntu since it has), and I'm fairly familiar with using the command line for basic tasks, I still don't really feel at home there and have never really used git.

But I'd love to proper step-by-step guide to using things like Hugo, GitHub pages, mkDocs etc with Surfer on Cloudron.

I'm sure I could do it and would likely find it suprisingly and satisfyingly easy once I know how, but e.g. right now I'm not even sure where I'd type the above commands? On my local machine? after ssh-ing into my VPS? in a Cloudron web terminal? See what I mean?

[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.