hugo.IsProduction at odds with staging configurations?

support
1

Hi all,

I’ve got a setup with a development, staging and production (= _default) configuration:

├── config
│   ├── _default
│   │   ├── config.toml
│   ├── staging
│   │   └── config.toml
│   └── development
│       └── config.toml

The staging is supposed to be the same as production, but deployed on staging.website.tld instead of www.website.tld, so the only config setting in staging is setting the baseURL.

With this setup, I can’t use the hugo.IsProduction function, as this returns false for the staging configuration (which is in itself correct, but defeats the idea behind having a staging deployment).

So the correct way of having a proper staging configuration is to use {{ if ne hugo.Environment "development" }} instead of hugo.IsProduction

Is this the “right” way to go about this?

(oh, the reason to not just deploy the production build on staging.website.tld is the very nature of generated sites: the domainname must be known at build time.)

Thanks,
Tom

2

I would do

if eq hugo.Environment "staging"

Or … it depend what you want to do.

3

My goal is to have 2 production configurations: production and staging. Where the only difference between the 2 is the baseURL. (And the development configuration adds more things like minify.enable = false.)

Hugo’s configuration infrastructure is flexible enough to allow this. Great. But the hugo.isProduction function is not. That function makes assumptions on the use of Hugo’s flexible configurations. It assumes: there are n configurations, only one of which is production.

So if you deviate from that, don’t use hugo.IsProduction. And I think everyone who creates staging deployments deviates from that assumption (as a good staging build is always exactly the same as production minus the baseURL).
Which would make the hugo.IsProduction function less than perfectly conceived by unintentionally framing the use of Hugo’s flexible configurations.

Just want to make sure I’m not misusing features or misunderstand the purpose.

4

OK. I do think, however, that it’s common to configure the baseURL in the OS environment (e.g. via netlify.toml), which would fit with your setup.

1 Like
5

Ah, yes. That would indeed be a great solution. Dove into the cli options just now, but I think the multilanguage multihost setup isn’t possible using cli/env?

[languages]
  [languages.nl]
    baseURL = "https://nl.staging.website.tld"
  [languages.en]
    baseURL = "https://en.staging.website.tld"

Forgot to mention this little detail:)

6

It should be possible via OS env. The only (current) limitation is that you cannot access single slice elements.

But in your case, this should work:

HUGO_LANGUAGES_NL_BASEURL=https://something

Note that if you hava an underscore in any of your config keys you want to override, you need to use another delimiter, e.g:

HUGOxLANGUAGESxNLxBASEURL=https://something
1 Like
7

Tested this solution, works perfectly!

:heart: Hugo

8

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