Inserting generated build output into public sub-directory

support
1

I’m using the same theme pulled with Hugo modules and configured from two directories which results in two completely different outputs, /docs and /resume. Both directories are at the root level. The expected result is to have the /resume content inside /docs/public, technically /docs/public/resume.

When I run:

hugo --gc --minify -s ./docs
Start building sites …
hugo v0.125.7+extended darwin/arm64 BuildDate=2024-05-08T14:46:24Z VendorInfo=brew
                   | EN
-------------------+-----
  Pages            | 53
  Paginator pages  |  0
  Non-page files   |  5
  Static files     | 15
  Processed images |  0
  Aliases          |  0
  Cleaned          |  0

hugo --gc --minify -s ./resume -d ./docs/public/resume
Start building sites …
hugo v0.125.7+extended darwin/arm64 BuildDate=2024-05-08T14:46:24Z VendorInfo=brew
                   | EN
-------------------+-----
  Pages            |  8
  Paginator pages  |  0
  Non-page files   |  0
  Static files     | 13
  Processed images |  0
  Aliases          |  0
  Cleaned          |  0

I would expect to have the relavant pages generated inside the ./docs/public/resume, but they are not. Is it something I’m missing? Thank you for your help.

2

The --destination is relative to the sites root you set with --source.

for the second call use an absolute path for --destination /home/user/site/docs/public/resume

3

Thank you for the reply @irkode. Is there a way to avoid the full path definition, with my scenario? This content is getting published to GitHub pages.

I believe with my scenario, there will be some file duplication, placed inside /resume directory. Not sure if is possible to skip files creation like 404.html etc.

Looks like hugo mod vendor can do exactly that.

4

Never played with vendoring, sry

in your github action you could determind the current workdir and use that to create the full path for destination.

You may disable generating some pages. See disableKinds in the docs

Both set of pages use the same theme. What’s the difference in generation you need with the two calls. Are they really two sites or just a subset of pages.

There might be more possibilities for example using mounts to achieve your desired result.

5

Yes, even if the same theme module is used, the output is completely different, starting with the menus and other Hugo.yaml customizations. Basically, the only common denominator is the theme template, which produces two completely different results.

6

Hard to tell (at least for me) without sources. The input part is the important thing and details on the desired result, like skipped pages(404).

You might checkout the other commandline options to not redirect the complete source but content and config.
Theres also a segments setting to render sites in parts

Just some ideas to play with

7

I finished publishing the website, which combines the source of /docs and /k3s-cluster directories. As you can see, the end result is very different, for example the navigation links at the top are specific to each directory. Looking at the hugo.yml workflow, I applied your suggestion and the site is rendered correctly. While this produces the expected result, my end-goal is to use a Hugo module as template, then in each specific directory to define only the customized variables/settings. This way, the end result will produce a unified site design, customized for each directory.

This is just an example, I will have several other directories added, while using the same Hugo module, as base template.

8

I’ve made some improvements to the configuration, now I have a global hugo.yaml and each directory contains only their specific settings.

9

:sunglasses: nice, sounds good

If it’s the website repo. There’s a deprecation warning you might want to checkout.

10

I was trying to determine where that warning is coming from, since is not set anywhere into settings. Looks like the theme author fixed that into main branch.

Also, I tried making usage of configDir inside configuration file, to avoid using the --config ../config/hugo.yaml,hugo.yaml external definition:

configDir: ../config,./

I presume is the chicken and egg rule that implies, you cannot define a configDir inside a configuration file. That does not work also, when I pass it as --configDir ../config,./ external setting.

11

@irkode I ended sorting all issues by creating a module. This way, I don’t have to deal anymore with directories and path definitions. The workflow is now nice and clean.

12

well done - gongrats

1 Like
13

For reference to other users, the proper fix is:

Feel free to look at the final workflow used for site deployment. As a side note, I’m using Renovate to automatically update the Go dependencies.

1 Like
14

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.