How to manage hugo_stats.json with multiple sites as branches?

Community Support
1

Hi all -

I am hosting multiple sites using a single codebase. Each site refers to the main branch’s Bookshop components, and the sites are stored as their own branch off main with their own unique content, assets, etc. CloudCannon will deploy each branch independently, and things, generally, work well until I want to bring the changes from the child branches back into the main branch.

hugo_stats.json always presents me with Github merge issues because the two branches, obviously, don’t line up.

I tried adding hugo_stats.json to .gitignore, but that resulted in some wonky behavior at build time on the CloudCannon side.

So, my question is – are there any best practices on how best to work with the ever-changing hugo_stats.json? I’m thinking there might be something I need to add to my build script, but I’m not smart enough to figure it out.

Here is what my build.toml looks like:

[buildStats]
enable = true
[[cachebusters]]
source = 'assets/notwatching/hugo_stats\.json'
target = 'css'
[[cachebusters]]
source = '(postcss|tailwind)\.config\.js'
target = 'css'

And here is an example of what a build script looks like for one of my sites:

"build-highq": "node ./scripts/copyCloudCannonConfig.cjs highq && hugo -e highq --gc --templateMetrics --templateMetricsHints --forceSyncStatic",

In this example, npm run build-highq copies this site’s specific CloudCannon configuration files to root, and then runs the site as a Hugo environment so it can pick up site-specific configuration settings.

Thanks for any guidance you can provide.

-Josh

2

I have done some more experimenting, and for some reason, CloudCannon isn’t creating a hugo_stats.json when it’s building my environment — even though the file is being created when I build on my local environment. So, the wonky behavior with which I began this post is attributable to the fact that the file isn’t being created on CloudCannon.

The investigation continues…

3

In my experience (not related to Cloud Cannon), trying to manage a distributed code base across multiple sites with different configs can cause problems.

DevOps tools are cheap and easy to use these days. I currently use Buddy, which manages a single codebase across multiple deployments.

4

Hi Josh,

Nice to see you in the community! Have you tried adding the hugo_stats.json to your CloudCannon SYNC_PATHS? It could be that the file is being generated as part of your site’s build on CloudCannon, but is not being saved back to your git repository - so it only exists in the CloudCannon build environment.

5

Thanks, Tom. I did some more research into the issue, and it turns out that the build inside CloudCannon didn’t create the Tailwind CSS class (for whatever reason). It works on my local environment, but it doesn’t when I do the same build inside CloudCannon. If I hardcode the class name in my Hugo template, it works fine – but when I add it as a variable, things go sideways.

This is similar to the issue you and I worked on a while back, so I’ll schedule some time to run through it with you to see if you have smarter ideas than me on how best to resolve. In the meantime, I’ve just hardcoded it.

2 Likes
6

No worries Josh, feel free to book a call whenever suits you and we can try get that sorted out.