0.17.18

🚀 Enhancements

Update `atmos`. Update tests @aknysh (#123)

what

• Update atmos
• Update tests

why

• settings.spacelift.stack_name_pattern allows overriding Spacelift stack names. Supported tokens: {namespace}, {tenant}, {environment}, {stage}, {component}

components:
  terraform:
    "test/test-component-override-2":
      settings:
        spacelift:
          workspace_enabled: true
          # `stack_name_pattern` overrides Spacelift stack names
          # By specifying the following `stack_name_pattern`, the final Spacelift stack name will be
          # `tenant1-ue2-dev-new-component` instead of `tenant1-ue2-dev-test-test-component-override-2`
          # By default (if `stack_name_pattern` is not specified), the stack name is generated using the pattern {tenant}-{environment}-{stage}-{component}
          # Supported tokens: {namespace}, {tenant}, {environment}, {stage}, {component}
          stack_name_pattern: "{tenant}-{environment}-{stage}-new-component"

If the stack name pattern is specified incorrectly or not specific enough, an error like this will be thrown:

Duplicate Spacelift stack name 'tenant2-ue2-new-component' for component 'test/test-component-override-2' in the stack 'tenant2/ue2/prod'.
Check if the component name is correct and the Spacelift stack name pattern 'stack_name_pattern={tenant}-{environment}-new-component' is specific enough.
Did you specify the correct context tokens {namespace}, {tenant}, {environment}, {stage}, {component}?

• When a stack name on the command line (e.g. atmos terraform plan test/test-component -s tenant1-ue2-dev) was the same as the name of the YAML config file in a subfolder inside the stacks folder, the stack was incorrectly detected (throwing an error "The stack 'xxx' does not exist") because it was considered as the folder path and not as a logical stack name (which is detected from the context)

references

• cloudposse/atmos#130