Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Resolves #813] Fix nested config Jinja render #1083

Merged
merged 1 commit into from
Sep 1, 2021

Conversation

lucasvieirasilva
Copy link
Contributor

This PR fixes nested config.yaml jinja substitutions (e.g {{ someKey }}).

Fixes issue: #813

Scenario

Currently, when the project structure has multiple nested config files and one of them tries to use a property from another config file sometimes works, and sometimes not, when not work the error message is <prop> is undefined..

Example structure:

root/
  config/
    prod/
      A.yaml
      config.yaml
      2/
        B.yaml
        config.yaml
        3/
          C.yaml
          config.yaml

config/prod/config.yaml

keyA: A

config/prod/2/config.yaml

keyB: {{ keyA }}-B

config/prod/2/3/config.yaml

keyA: {{ keyB }}-C

keyB should render the value A-B and keyC should render the value A-B-C

When running sceptre launch prod command the ConfigReader class doesn't follow a correct order to process the files, and sometimes the config object already has all the properties, sometimes not.

Solution

Sceptre already has a concept of recursive read in the ConfigReader class that reads all the config.yaml files recursively based on the parent path, and already has the config dict object with all the properties in the correct place, but when call the _render function just pass the stack_group_config that only contains the processed stack_group_config, which is fine when the files follow the correct order to be processed.

However, if the ConfigReader combines the current recursive object with the stack_group_config the _render will have all the required properties, doesn't matter which file order will be used to process the stacks.

PR Checklist

  • Wrote a good commit message & description [see guide below].
  • Commit message starts with [Resolve #issue-number].
  • Added/Updated unit tests.
  • Added/Updated integration tests (if applicable).
  • All unit tests (make test) are passing.
  • Used the same coding conventions as the rest of the project.
  • The new code passes pre-commit validations (pre-commit run --all-files).
  • The PR relates to only one subject with a clear title.
    and description in grammatically correct, complete sentences.

Approver/Reviewer Checklist

  • Before merge squash related commits.

Other Information

Guide to writing a good commit

@zaro0508 zaro0508 requested a review from ngfgrant August 17, 2021 15:38
@zaro0508
Copy link
Contributor

Does this also fix issue #937 ?

@lucasvieirasilva
Copy link
Contributor Author

Does this also fix issue #937 ?

No, it is a different issue.

@zaro0508 zaro0508 merged commit 381d284 into Sceptre:master Sep 1, 2021
mrowlingfox pushed a commit to fsa-streamotion/sceptre that referenced this pull request Sep 21, 2021
This PR fixes nested `config.yaml` jinja substitutions (e.g `{{ someKey }}`).

Fixes issue: Sceptre#813

#### Scenario

Currently, when the project structure has multiple nested config files and one of them tries to use a property from another config file sometimes works, and sometimes not, when not work the error message is `<prop> is undefined.`.

Example structure:

```text
root/
  config/
    prod/
      A.yaml
      config.yaml
      2/
        B.yaml
        config.yaml
        3/
          C.yaml
          config.yaml
```

`config/prod/config.yaml`
```yaml
keyA: A
```

`config/prod/2/config.yaml`
```yaml
keyB: {{ keyA }}-B
```

`config/prod/2/3/config.yaml`
```yaml
keyA: {{ keyB }}-C
```

`keyB` should render the value `A-B` and `keyC` should render the value `A-B-C`

When running `sceptre launch prod` command the `ConfigReader` class doesn't follow a correct order to process the files, and sometimes the config object already has all the properties, sometimes not.

#### Solution

Sceptre already has a concept of recursive read in the `ConfigReader` class that reads all the `config.yaml` files recursively based on the parent path, and already has the config `dict` object with all the properties in the correct place, but when call the `_render` function just pass the `stack_group_config` that only contains the processed `stack_group_config`, which is fine when the files follow the correct order to be processed.

However, if the `ConfigReader` combines the current recursive object with the `stack_group_config` the `_render` will have all the required properties, doesn't matter which file order will be used to process the stacks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants