cloudposse/atmos v1.11.0

on GitHub

what

• Add disabled field to component validation steps
• Add verbose field to custom command steps
• Expose component config in custom commands

why

• Add disabled field to component validation steps to be able to to skip the validation step. disabled is set to false by default and the validation step is allowed if disabled attribute is not specified. This is useful when we add component validation in settings.validation at environment/tenant/stage/base component level, but we want to disable validation for a particular component in the inheritance chain

  terraform:
    infra/vpc:
      settings:
        validation:
          check-infra-vpc-component-config-with-opa-policy:
            schema_type: opa
            # 'schema_path' can be an absolute path or a path relative to 'schemas.opa.base_path' defined in `atmos.yaml`
            schema_path: validate-infra-vpc-component.rego
            description: Check 'infra/vpc' component configuration using OPA policy
            # Set `disabled` to `true` to skip the validation step
            # `disabled` is set to `false` by default, the step is allowed if `disabled` is not declared
            disabled: true

• Add verbose field to atmos custom command steps to show just the command output without any additional messages that atmos prints to the console. This is useful when we want to parse the custom command output and select a specific field using jq or yq. verbose is false by default, no need to specify it (if verbose: false is omitted, it will be set to false automatically). You need to explicitly set verbose: true to make the command output verbose.

- name: ping
  description: This command plays ping-pong
  verbose: false
  steps:
    - echo pong

The above command will just output pong without any additional messages to the console.

• Expose component config in custom commands to be able to use the entire component config in the custom commands' Go templates. This allows using all component sections in custom commands, including vars, settings, env, metadata, backend, and terraform workspace, which in turn will allow creating complete workflows for provisioning terraform/helmfile components by just using custom commands. If a custom command defines 'component_config' section with 'component' and 'stack', atmos automatically generates the component config in the stack and makes it available in {{ .ComponentConfig.xxx.yyy.zzz }} Go template variables, exposing all the component sections (which are also shown by atmos describe component command)

For example, if we define the following custom command in atmos.yaml:

- name: show
  description: Execute 'show' commands
  commands:
    - name: component
      description: Execute 'show component' command
      verbose: false
      arguments:
        - name: component
          description: Name of the component
      flags:
        - name: stack
          shorthand: s
          description: Name of the stack
          required: true
      # If a custom command defines 'component_config' section with 'component' and 'stack', 'atmos' generates the config for the component in the stack
      # and makes it available in {{ .ComponentConfig.xxx.yyy.zzz }} Go template variables,
      # exposing all the component sections (which are also shown by 'atmos describe component' command)
      component_config:
        component: "{{ .Arguments.component }}"
        stack: "{{ .Flags.stack }}"
      # steps support Go templates
      steps:
        - 'echo Atmos component: {{ .Arguments.component }}'
        - 'echo Atmos stack: {{ .Flags.stack }}'
        - 'echo Terraform component: {{ .ComponentConfig.component }}'
        - 'echo Backend S3 bucket: {{ .ComponentConfig.backend.bucket }}'
        - 'echo Terraform workspace: {{ .ComponentConfig.workspace }}'
        - 'echo Namespace: {{ .ComponentConfig.vars.namespace }}'
        - 'echo Tenant: {{ .ComponentConfig.vars.tenant }}'
        - 'echo Environment: {{ .ComponentConfig.vars.environment }}'
        - 'echo Stage: {{ .ComponentConfig.vars.stage }}'
        - 'echo settings.spacelift.workspace_enabled: {{ .ComponentConfig.settings.spacelift.workspace_enabled }}'
        - 'echo Dependencies: {{ .ComponentConfig.deps }}'
        - 'echo settings.config.is_prod: {{ .ComponentConfig.settings.config.is_prod }}'

we can run it like this:

atmos show component infra/vpc -s tenant1-ue2-prod

and the command output will be:

Atmos component: infra/vpc
Atmos stack: tenant1-ue2-prod
Terraform component: infra/vpc
Backend S3 bucket: cp-ue2-root-tfstate
Terraform workspace: tenant1-ue2-prod
Namespace: cp
Tenant: tenant1
Environment: ue2
Stage: prod
settings.spacelift.workspace_enabled: true
Dependencies: [catalog/terraform/spacelift-and-backend-override-1 catalog/terraform/test-component-override-3 catalog/terraform/vpc mixins/region/us-east-2 mixins/stage/prod orgs/cp/_defaults orgs/cp/tenant1/_defaults orgs/cp/tenant1/prod/_defaults orgs/cp/tenant1/prod/us-east-2]
settings.config.is_prod: true

This is also useful to be able to define free-style config in settings section and then use it in custom commands. For example, if we define settings.config.is_prod: true|false at the account level, then for each component in all stacks we could detect if the component is categorized as prod or non-prod by just running one custom command with the following step:

 - echo {{ .ComponentConfig.settings.config.is_prod }}