Development/Production workflow revisited

Back in google groups we had a discussion about rendering for development or production. Bascially workflow issues

Several notions about how were discussed. (should we repeat the highlights, agreements?)

Just wondering where this stands and if coding is happening for v0.13/

The more I get into Hugo the more this seems to be an important workflow issue.

One big reason among others is the baseurl setting in the config file which I must change manually from dev/pro

It would be great too if render “destination” could be specifed in the config file (but till keep the command line swtich)

Here is my idea for this workflow thing.

Data in the frontmatter of documents or the config file could be triggered(used/ignored) based on a workflow switch in the CLI.
Kinda like this -w for say workflow followed by the workflow name, Then in any toml/json/yaml (config or frontmatter) any data item could have an additional parameter (none for defualt) specifying which workflow is to use this data item.

e.g -w dev, or -w pro

One thing I see is that I could have workflows for indiivduals within a project. I mean say person x, had pictures on his windows box in such a directory and person y the same pictures put in a different path on their linux box then to statsfy them both they just put -w personx or -w persony into the CL, and use personx or persony parameter in any indvidual specific data item. I’m thinking too that one could combine “workflows” in the CL as in -w dev,personx

This then totally avoids issues of custom configs for different content contributors and allows that git workflow thing to work seamless among contirbutors for a document/site.

For example I have set up a data item in the frontmatter that holds a path to a picture gallery. In this way in the document I only use the filename without path. Then for production I need that to change to the cloud based path from a local path(manually now). You can see that if I do this manually and push then anyone pulling this for dev work will get the production path unless right after rending I edit it back (not a good workflow!).

Others thoughts? How easy to code this?


Just an overall suggestion - If Steve or others would point out appropirate source locations and outline an approach/caveats to implementing feature requests then some of the rest of us might be able to jump in to actual coding of Hugo.

KISS = Keep It Simple Stupid

#!/bin/sh

nohup grunt &

hugo version && echo "--------------------------------------------------\n" &&  hugo server --baseUrl=http://bep.local/ -D -w -d dev

Above is a shell script I use on my site to start a “Hugo dev server”, some comments:

  • baseUrl overrides the production value in config (if I had not set it here I’d gotten localhost, but I need a proper name for my local dev server)
  • I build to /dev - my production build goes to /public - just to avoid messing up if I forget to turn off my dev server
  • grunt builds static files (CSS, JS) (also watching for changes in /assets)

In addition to that I have constructions like the one below for “only do this in production mode”:

{{ if not .Site.BuildDrafts }}do some production stuf{{ end }}
1 Like

I actually do the same thing as @bjornerik. I have a couple shell scripts and do some conditional logic in my templates.

However I do see some value in a few simple commands that capture commonly used settings. I think it really increases the usability.

I think a couple things still need to happen before we go down this route though. Specifically we need to figure out the best way to organize the config file(s). Should dev & prod use different config files… or should they have separate parts of the same config file. (I think separate).

If it is separate, then I want to get data loading working first.

What should the settings be?

Dev is the obvious one. What else is there? Which settings should be in dev? I think Hugo dev should equal hugo server -D, but probably more as well.

so what has come of this? I am at the point I want to incorporate something. @bjornerik seems to be using -D to do this which is fine although basing production on a buildDrafts flag might be confusing especially if someone wanted to build drafts or not for a production run.

I think for now I am just going to put a parameter in the config.toml which I use like he suggests {{ if Site.Production }}do some production stuf{{ end }}. Then if the CLI ever gets a production swtich I can just copy and replace with whatever parameter name (state) is passed from the CLI. Maybe we could at least agree now on a production/dev parameter name even it’s awhile (or never) till it gets implimented thus saving me/us future code edits. It doesn’t matter to me the logic although I prefer development by default so in my case Production is false when developing.

BTW this gets back to my wider audience post. If noobs are going to use Hugo can’t have them editing the config.toml. “Production” is outside their vocabulary. They need a bash script associated with an icon they can click on that does the production run so then the script can push it to their server.

Just checking in on this again.

I had another reason to like a production switch in the CLI.

With it I could conditionally swtich over from local loading of java and css to their equivalent cdns.

Re-purposing another swtich like some have done with builddrafts is ok but even if a production switch doesn’t get incorporated this go round how about a generic “custom” switch that doesn’t do anything other than pass it’s value for conditional use. Famous words, but that should be easy to thrown in no?

1 Like

@dkebler Recently, I’ve been using environment variables for this. You can use the getenv function in templates. Here’s a rough example:

{{ $cssFilename := cond (eq (getenv "ENV") "dev") "style" "style-dev" }}
<link rel="stylesheet" href="/css/{{ $cssFilename }}.css">

Here are some corresponding make commands for different environments (build is prod, serve is dev):

build:
    ENV=prod hugo

serve:
    ENV=dev hugo serve