Output path in toml config file?

support
1

Hello,

I am pushing some content created with Hugo to the root of a git repository, in the “master” branch. Then a hook on the server push it to the web server, online. As this is a simple Git repository, I can’t do something like Github’s gh-pages branch. I can"t change this default behavior.

However, I need to have the Hugo files in the same repository, so I would like to change the default output path of the website like this:

  • output should be in the root folder of the repo ("/")
  • the hugo files should be in a subfolder (e.g “/hugo-files/”)
  • using “hugo” command would just generate the file in “/” instead of “/hugo-files/public/”

So, setting a different output path in a config file would be awesome.

Is this possible? I didn’t find a config variable in the doc.

If not, what would you recommend?

2

Take a look at https://gohugo.io/tutorials/automated-deployments/

Personally, I use Wercker along with Rsync to deploy to the web server, but there are quite a few different options if you check the link.

3

In this case, only a simple setup is possible. No executable script, and no build engine like Jenkins.

So just a good Git config, or a Hugo configuration, that would be awesome.

4

Actually, I would like to set the parameter of “-d” command line option directly in the toml config file. This way I don’t need anymore to add it to the hugo command line.

-d, --destination string         filesystem path to write files to
5

It seems this is:

# filesystem path to write files to
publishDir:                 "public"

see: https://gohugo.io/overview/configuration/#configuration-variables

Now I need to find how to set my specific path.

6

You can try to just set publishDir to an empty string and see if that writes your output to the root of your project, but I have to wonder about the obvious problems with muddying source and output in a single repo.

I would recommend a separate repo for the output that you then set up as a submodule within your source repo…

7

Given your restrictions, I would go with @rdwatters suggestion, at the very least keep the content in a separate repo. But if that for some reason doesn’t work for you, you can do:

publishDir = "../"

The path is relative to where the hugo is run, I think. I generated this tree:

.
├── categories
│   └── index.xml
├── hugo
│   ├── archetypes
│   │   └── default.md
│   ├── config.toml
│   ├── content
│   │   └── posts
│   │       └── blah.md
│   ├── data
│   ├── layouts
│   ├── static
│   └── themes
├── index.xml
├── posts
│   └── index.xml
├── sitemap.xml
└── tags
    └── index.xml

With this config.toml:

baseURL = "http://example.org/"
languageCode = "en-us"
title = "My Weird Hugo Setup"

publishDir = "../"

Important caveat!!

If you are pushing that whole repo to a web server, it will include your Hugo site, which is at best is weird, and at worst a waste of bandwidth since you are uploading all the content twice. And while you should never keep credentials in a repo, this would end up sharing information about a private repo that you don’t want webcrawlers to know.

Okay, if that was useful, you can repay my helpfulness with a hint as to why you have such a weird setup. :slight_smile:

8

Oh yeah, you also could override your Hugo site directory with the wrong content structure. You’d be able to rollback, but that is something to consider.

9

I actually set “publishDir” to “…/” and I am using it like you describe it. It’s working well, you can have a look at:


Thanks.

So why I do it this way? Historically, I was using Hugo with Github pages feature, and the gh-pages branch, following the very good tutorial in Hugo’s doc. However, this is possible to use a config like that when you can 1/ upload you files to a git repo and 2/ you can set a hook to push only a specific branch content to the web server.

On eclipse.org, you push the static website in a git repo, at the root of the “main” branch. And a hook push that to the web server. That’s all. This is very simple, but there is a collaborative issue: where do you store the Hugo source files, so anyone can clone the repo, add/modify content, and then push everything. And keep it simple for newbies.

In this case, I would like to avoid having one repo for Hugo sources, an other one for the actual website, and scripts or build jobs (maintenance, doc…). I needed a simple repo, a simple workflow, described in a simple howto. That was the constraint, so any non developer working on a website content could update it. (Command line is already a pain for non coder people, usually)

Now, you know the story.

Maybe there is a better way, using a specific Git configuration, but after many trials, and research, I didn’t find a good way to do it. If you know how I could have Hugo’s output in “master” /, and the Hugo’s sources in an other branch, that would be awesome and I would try that too. This way, everything would be in the repo, but only the website would be on the web server.

10

I getcha on the sentiment, but I am not sure this is gonna work out, and I will tell ya why: you are gonna need them to either edit content without seeing how it will look finished, or provide the editors of the site with instructions for running Hugo locally in a way that matches everyone else.

The presumption is that in order to edit a page, of instance, I would clone the repo, make the changes, and either:

  • Merge the change, hope it looks okay
  • Run hugo locally, check changes and merge
  • Run hugo locally, commit changes to public and merge

I have two points. First, hugo is a little difficult. And second, committing all the changed files on an edit change generates a lot or files changes, compared to just tracking the content and generating the site elsewhere.

I don’t know about the eclipse infrastructure, but if you have access to a CI server, I’d ask for that. It would simplify yer life. :slight_smile:

11

We use Gerrit so this is very easy to push modifications to a git repo, even for beginners. Yes, you are right, each time, it creates a lot of changes. But we don’t change the content that much, and just add a blog article once every 2 months. So that will do the job, even if it is not perfect.

My plan is to write a howto, with simple steps, so they will clone the repo, add content, check locally, and then push.
At least, this way, one committer can do it. Or a content writer can push, and just ask a committer to accept the commit. That’s quite simple.

And yes, we have a CI server. We did a Hugo website, using the CI server to build the static website, push the files in the good git repo, … But actually, it has not been well documented, and it is not easy at all to use it.

The last point is that people using Hugo to create website for Eclipse projects may be a developper. But many people are just marketing people, and using Markdown and command line is already difficult for them. They will never have the skills to maintain a CI and/or a build script.

It seams to me that the best way is to keep a simple way to do it, following documentation from Hugo, Gerrit, and Eclipse infrastructure. This way I am sure that it will always work well. if it means committing all the changes, that’s ok :slight_smile:

Thanks for your answers, that helped a lot to think about it.

12

This, in my experience, is a very different issue. Have you considered adding one of the many snazzy new CMS layers for “non-technical” users? I have limited experience but found both Netlify and especially Forestry’s products to be impressive, but I usually defer to @budparr on these matters.

13

The infra for Eclipse’s projects websites (mainly general information, download links and howtos) is available for static websites only. Hugo is a good way to provide modern websites for visitors. And a not so complicated way to build a website. So we will continue to use it.

Netlify and Forestry seems to be something between infrastructure, CDN, host, and build tools… that seems difficult to replace a legacy infra with that, unless you really want to start from scratch. But for a brand new web infra, that seems to be a good and fast choice. However, I won’t ask non coder people to use them: they looks very technical.

14

You won’t ask non-coders to use a CMS? We are on very different pages. Glad it’s all working out for you.

1 Like
15

Netlify and Forestry are not CMS. Wordpress is a CMS.

When I can of course I prefer CMS for non coders. But this is not always available.

16

You should write both of them and let them know that their URLs and marketing copy are fallacious.

Or…

You can read through the descriptions of the products. If you are building a site in Hugo where you want “non-technical users” to make changes but preserve your git-based workflow, both of the above (as well as DatoCMS) put a nice JS UI on top of Hugo but are decoupled in the event the aforementioned users miraculously become more comfortable with PRs, markdown, and text editors.

1 Like
17

That’s what I say. Hugo is a CMS. Wordpress is a CMS. Netlify and Forestry are not CMS. They are solutions and tooling to push content online. That is not exactly what one can call a CMS. In my case, it would just add something new to learn, configure and maintain in the workflow, plus a cost.

But if you read me carefully, I need the simplest workflow, using Git, Hugo, eclipse.org hosting, and if possible, make it to work following their documentation.

1 Like