Jinja templating on nested stack_group config.yaml not working properly

[schlichtanders]

Just run into an unexpected behaviour of sceptre.

I have a directory layout like

config
  /subfolder1
    /sub1subfolder1
      config.yaml  # config_sub1subfolder1
    config.yaml  # config_subfolder1
  /subfolder2
    config.yaml  # config_subfolder2
  config.yaml  # config_global

I defined a couple of variables in all configs and now would like to create an aggregation of a couple of these within config_sub1subfolder1.
It happens now that the templating fills in variables with values defined in config_subfolder2, despite they have a different value in config_subfolder1(which should be the correct one to be used).

I.e. somehow the templating works, but it uses values from unrelated other subfolders.

I hope, this can be fixed, as this breaks the reliability of stack_group level variables, which is a powerful feature to have.

[zaro0508]

it would help if you could provide all the files needed to reproduce this issue. just a simple set of config.yaml and template files.

[schlichtanders]

as often this is a bit of work, as I cannot share my real setup but would need to minify it.
I was hoping that if a developer knows that something like this happens, it can be spotted rather quickly in the code.

If I find time resources to build a minimal working example, I will do

[schlichtanders]

maybe this helps:
in config_sub1subfolder1, the jinja templating which is not working is something like the following

subfolder1aggregation={CustomVariable}-{AnotherCustomVariable}

where CustomVariable and AnotherCustomVariable are defined with different values in config_subfolder1 and config_subfolder2 respectively. Say customvalue1 and anothercustomvalue1 for config_subfolder1, and customvalue2 and anothercustomvalue2 for config_subfolder2.

As said, despite the above little assignment is placed under subfolder1, the current sceptre inserts values from subfolder2, so that I finally can have something like

subfolder1aggregation=customvalue2-anothercustomvalue2

that of course breaks the use of such intermediate variables

[ngfgrant]

#731 Which is now in master might fix this. @schlichtanders can you test locally?