Site build fails with --cacheDir set to a subdirectory of the root, succeeds if cached elsewhere

maueroats commented 8 months ago

Any reason why Hugo 0.123.1 would fail to build my docsy site when the cache file is in the root of the site (the same directory as the site's config.toml file)? This worked in the previous version I had installed (0.121 I believe). I verified that this builds fine with 0.119.0 and fails with 0.123.1.

$ hugo version
hugo v0.123.1-3f8434a62fc91a50f4e5bd43a4435d2d301844ff+extended linux/amd64 BuildDate=2024-02-21T08:17:45Z VendorInfo=gohugoio
$ hugo --cacheDir "/tmp/t1234" # build succeeds - /tmp/t1234 did not exist beforehand
$ hugo --cacheDir "$HOME/t1234" # build succeeds - $HOME/t1234 did not exist beforehand
$ hugo --cachedir "$PWD/t1234" # build fails

I verified that the cacheDir does not exist before each test.
I remove the output directory (public) before each test.

Result of failed build:

hugo: downloading modules …
hugo: collected modules in 16064 ms
Start building sites … 
hugo v0.123.1-3f8434a62fc91a50f4e5bd43a4435d2d301844ff+extended linux/amd64 BuildDate=2024-02-21T08:17:45Z VendorInfo=gohugoio

Total in 20945 ms
Error: error building site: TOCSS: failed to transform "/scss/main.scss" (text/x-scss): "/home/user/Documents/2023b/2023-2024--HOME/www/t1234/modules/filecache/modules/pkg/mod/github.com/twbs/bootstrap@v5.2.3+incompatible/scss/_mixins.scss:6:1": File to import not found or unreadable: vendor/rfs.

What version of Hugo are you using (`hugo version`)?

$ hugo version
hugo v0.123.1-3f8434a62fc91a50f4e5bd43a4435d2d301844ff+extended linux/amd64 BuildDate=2024-02-21T08:17:45Z VendorInfo=gohugoio

Does this issue reproduce with the latest release?

Yes.

Modules

go.mod contains:

module [site]
go 1.19
require (
    github.com/google/docsy v0.9.1 // indirect
    github.com/google/docsy/dependencies v0.7.2 // indirect
)

maueroats commented 8 months ago

Reproduces with snap version 0.123.1+git1.6da1d8f37:

$ hugo version
hugo v0.124.0-DEV-6da1d8f370624b1a3640076b1e60380b0d8b2f92+extended linux/amd64 BuildDate=2024-02-21T08:30:57Z VendorInfo=snap:0.123.1+git1.6da1d8f37

Same failure mode.

The original testing was done with the extended hugo installed from a tarfile on github, so snap was not a possible factor.

jmooring commented 8 months ago

I am unable to reproduce the problem with a test repository that loads a remote content module.

$ hugo --cachedir "$PWD/t1234"

hugo: collected modules in 1789 ms
Start building sites … 
hugo v0.124.0-DEV-ea0ba9751d9b6a5dec9261676287832717c0ca17+extended linux/amd64 BuildDate=2024-02-22T15:41:43Z

                   | EN | DE  
-------------------+----+-----
  Pages            | 12 |  6  
  Paginator pages  |  0 |  0  
  Non-page files   |  3 |  0  
  Static files     |  2 |  2  
  Processed images |  0 |  0  
  Aliases          |  1 |  0  
  Cleaned          |  0 |  0

Works great. Without access to your site troubleshooting is... difficult.

maueroats commented 8 months ago

Thanks for looking at this. Sorry I did not think it would fail to reproduce everywhere. The issue reproduces with extended Hugo 0.123.2 and the Docsy demo site. Details and a repository below.

Repository:

git clone https://github.com/maueroats/hugo-docsy-bugdemo

I started with the Docsy theme demo site, ran the required npm install commands (listed below) and then reproduced the behavior with a freshly downloaded extended Hugo 0.123.2 installed from tarball.

You will know better than me, but I needed these steps:

npm install -D autoprefixer
npm install -D postcss-cli
npm install -D postcss

System: Ubuntu 22.04.3 LTS

jmooring commented 8 months ago

I am able to reproduce the problem with your repo using v0.123.2. I cannot reproduce the problem with v0.122.0. So yeah, we either broke or fixed something, but I have a difficult time getting excited about it.

Why would you want to do this?

hugo --cacheDir "$PWD/t1234"

Instead of sharing the cache with other projects on your system?

This smells like a "vendor" directory collision with Go modules.

maueroats commented 7 months ago

The #wontFix response is fine with me.

I no longer know why the system was setup that way... done years ago and never touched since. It was set up that way when Hugo got caching.

Possibly because originally the cache was in /tmp and the system was rebooted often?

github-actions[bot] commented 7 months ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

gohugoio / hugo