YAML config causes null objects
# 🌱|help-and-getting-started
m
project.garden.yaml
Copy code
one:
  config:
    name: "defaultvalue"
    foo: "bar"
if I have a config for an environment like this clientenv.yaml
Copy code
one:
  config:
    # foo: "bar2"
then when referencing
{$var.one.config.name}
in a kubernetes deployment manifest I get an error
Copy code
errors:
  - detail:
      results:
        task.one-migrate:
          type: task
          description: running task one-migrate in module one-server
          key: task.one-migrate
          name: one-migrate
          error:
            detail:
              err:
                detail:
                  value: null
                  nodePath: []
                  fullPath: var.one.config.name
                  opts:
                    allowPartial: true
                    unescape: true
                    stack: []
                type: configuration
            type: template-string
Is this the intended behaviour that having the
config:
section without anything in it is effectively doing
config: {}
and blanking/nulling any default values?
b
Hi @mammoth-flag-56137 I'm not sure what you mean with a "config section", but if you're assigning a project-level variable in the project.garden.yml called
one
, and then you're assigning a module-level variable in
clientenv.yaml
called
one
, the latter will take precedence. See also: https://docs.garden.io/using-garden/variables-and-templating#variable-precedence-order
m
In the clientenv.yaml one.config section I mean
b
Can you share the structure of clientenv.yml?
m
It works fine if you eg uncomment the foo: bar2 line
Clientenv.yaml
Copy code
one:
  config:
    foo: "bar2"
That will work fine and one.config.name will have the default value of "defaultvalue" from project.garden.yaml
If you comment out the 3rd line then one.config.name in templates results in the above error about null
Clientenv.yaml is being specified to garden via the --env cli flag , can't give the exact specifics it's my day off and I'm phone posting
b
ah, I thought it was a module yaml file or something! Sorry for the confusion
m
No worries
b
but --env is for specifying the environment name, right?
do you mean env-specific var files like garden..env ?
m
Yeah the way we have garden setup is a set of defaults then client specific overrides in their own yamls
Copy code
- garden --env=$ENVIRONMENT $IMAGE_VARS --yes plugins kubernetes cluster-init
    - garden --env=$ENVIRONMENT $IMAGE_VARS --yes -l=silly -o=yaml deploy
Copy code
if [[ $ENVIRONMENT == "preview" ]]; then
    if [[ -f "environments/${ENV_PATH}.yaml" ]]; then
        cp -f "environments/${ENV_PATH}.yaml" ./garden.env.yaml
    else
        cp -f "environments/preview/${PREVIEW_BASE}.yaml" ./garden.env.yaml
    fi
fi

if [[ $ENVIRONMENT != "preview" ]]; then
    if [[ -f "environments/${ENV_PATH}.yaml" ]]; then
        cp -f "environments/${ENV_PATH}.yaml" ./garden.env.yaml
    else
        echo "Non-preview environment was specified and no environment file exists at `environments/${ENV_PATH}.yaml`."; 
        exit 1;
    fi
fi
so we copy specific envs to garden.env.yaml (which is by default empty) to override for each env
minimum example is basically: garden.project.yaml
Copy code
one:
  config:
    name: "defaultvalue"
    foo: "bar"
garden.env.yaml
Copy code
one:
  config:
    # foo: "bar2"
then whatever module that uses
{$var.one.config.name}
will be trying to use null
@big-spring-14945 is that a better explaination?
also if you have instead garden.env.yaml
Copy code
one:
  config:
    foo: "bar2"
then
{$var.one.config.name}
will be "defaultvalue"
b
I agree that the behaviour around the varfiles seems inconsistent. I have opened a bug report here: https://github.com/garden-io/garden/issues/3592
Do you have a way to work around this? I think we won't find time at least this quarter to address this
m
Just don't leave blank sections like I did and it works fine
b
Great to hear, thanks for reporting this
19 Views