8000 Releases · cloudposse/atmos · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Releases: cloudposse/atmos

v1.179.0-rc.0

04 Jun 01:05
@cloudposse-releaser cloudposse-releaser
v1.179.0-rc.0
c86b34f
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.179.0-rc.0 Pre-release
Pre-release
add pager to atmos describe affected command @samtholiya (#1255) ## what
  • Updated describe affected with pager

image

why

  • Makes easier for users to view the content

references

Summary by CodeRabbit

  • Refactor

    • Improved modularity and maintainability of the "describe affected" command, including more robust CLI argument parsing and error handling for conflicting flags.
    • Separated argument parsing from execution logic, enhancing testability and code clarity.
    • Refactored syntax highlighting utilities for clearer lexer and formatter selection with terminal presence caching.

  • Bug Fixes

    • Corrected a YAML configuration to reference the intended Terraform output variable.
    • Updated test snapshots and test cases for accurate YAML formatting and pager settings.

  • Tests

    • Added and updated unit tests for CLI argument parsing, command execution, and syntax highlighting, including new mock implementations for better test coverage.

  • Style

    • Improved code readability and structure in syntax highlighting utilities.

Contributors

samtholiya
Loading

v1.178.0

03 Jun 03:52
@cloudposse-releaser cloudposse-releaser
v1.178.0
83a5cc3
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.178.0
Update `atmos terraform version` and `atmos helmfile version` commands @aknysh (#1274)

what

why

  • When executing atmos terraform version and atmos helmfile version commands, take into account the command setting in atmos.yaml. The command setting specifies the executable, which can be terraform, tofu, helmfile, or a path to an executable.
components:
  terraform:
    # Optional `command` specifies the executable to be called by Atmos when running Terraform commands
    # If not defined, `terraform` is used
    # Examples:
    # command: terraform
    # command: /usr/local/bin/terraform
    # command: /usr/local/bin/terraform-1.8
    # command: tofu
    # command: /usr/local/bin/tofu-1.7.1
    # Can also be set using 'ATMOS_COMPONENTS_TERRAFORM_COMMAND' ENV var, or '--terraform-command' command-line argument
    command: terraform
components:
  helmfile:
    # Optional `command` specifies the executable to be called by Atmos when running Helmfile commands
    # If not defined, `helmfile` is used
    # Examples:
    # command: helmfile
    # command: /usr/local/bin/helmfile
    # Can also be set using 'ATMOS_COMPONENTS_HELMFILE_COMMAND' ENV var, or '--helmfile-command' command-line argument
    command: helmfile
atmos terraform version

  Terraform v1.7.3
  on darwin_arm64
atmos terraform version

  OpenTofu v1.7.1
  on darwin_arm64
atmos helmfile version

  Version            v1.1.0
  Git Commit         "brew"
  Build Date         19 May 25 18:20 EDT (1 week ago)
  Commit Date        19 May 25 18:20 EDT (1 week ago)
  Dirty Build        no
  Go version         1.24.3
  Compiler           gc
  Platform           darwin/arm64
Don't use terraform workspace in `!terraform.output` when backend is `http` @astephanh (#1268)

what

  • Don't use terraform workspace in !terraform.output YAML function when backend is http

why

  • Using http backend for remote state ended in an error
Fix: Bad characters when using the `!include` function @Cerebrovinny (#1249)

what

  • Fixed issue with YAML processing where strings starting with # character were being interpreted as comments and returning null values
  • Added special handling for strings starting with # by setting them to use single-quoted style in YAML nodes

why

  • Strings starting with # were being incorrectly processed as comments in YAML, causing the !include function to return null values
  • This was causing unexpected behavior when users tried to include values that started with the # character
  • Ensure that all strings starting with # are properly preserved throughout YAML processing

Contributors

aknysh, astephanh, and Cerebrovinny
Loading

v1.178.0-rc.1

28 May 01:06
@cloudposse-releaser cloudposse-releaser
v1.178.0-rc.1
c2db173
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.178.0-rc.1 Pre-release
Pre-release
Fix: Bad characters when using the !include function @Cerebrovinny (#1249) ### what
  • Fixed issue with YAML processing where strings starting with # character were being interpreted as comments and returning null values
  • Added special handling for strings starting with # by setting them to use single-quoted style in YAML nodes
  • Implemented this fix in multiple places: filetype package, YAML utils, and YQ utils

why

  • Strings starting with # were being incorrectly processed as comments in YAML, causing !include function to return null values
  • This was causing unexpected behavior when users tried to include values that started with # character
  • Ensure that all strings starting with # are properly preserved throughout YAML processing

references

Summary by CodeRabbit

  • Bug Fixes

    • Improved handling of YAML strings starting with # to ensure they are correctly preserved and not misinterpreted as comments, including when using custom tags, !include directives, or YQ expressions.

  • Tests

    • Added comprehensive tests covering YAML parsing, node processing, and inclusion scenarios to verify correct handling of strings beginning with #.
    • Introduced tests for utility functions related to YAML processing, ensuring robust error handling and correct style application.

Contributors

Cerebrovinny
Loading

v1.178.0-rc.0

27 May 01:04
@cloudposse-releaser cloudposse-releaser
v1.178.0-rc.0
6bde3fc
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.178.0-rc.0 Pre-release
Pre-release
  • No changes
Loading

v1.177.0

26 May 15:53
@cloudposse-releaser cloudposse-releaser
v1.177.0
6bde3fc
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.177.0
Update `atmos describe affected` command @aknysh (#1267)

what

  • Update atmos describe affected command
  • Add affected_all attribute to the output of atmos describe affected to show all component sections and attributes that were changed
  • Update docs
  • Add unit tests

why

  • Improve usage of the atmos describe affected command in CI/CD, e.g. GitHub actions

  • affected_all will allow detecting everything that was changed for a component in a stack (including Terraform configurations/components/modules) and ack on the changes

    For example, if you make changes to the vars and settings sections of the component component-1 in the
    nonprod stack, and execute atmos describe affected, you will get the following result:

      [
    {
      "component": "component-1",
      "component_type": "terraform",
      "stack": "nonprod",
      "stack_slug": "nonprod-component-1",
      "affected": "stack.vars",
      "affected_all": [
         "stack.vars",
         "stack.settings"
      ]
    }
  ]

    If you create a new Terraform/Tofu component, configure a new Atmos component component-1 in the
    nonprod stack, and execute atmos describe affected, you will get the following result:

    [
  {
    "component": "component-1",
    "component_type": "terraform",
    "stack": "nonprod",
    "stack_slug": "nonprod-component-1",
    "affected": "stack.metadata",
    "affected_all": [
      "stack.metadata",
      "stack.vars",
      "stack.env",
      "stack.settings",
      "component"
    ]
  }
]

    where:

    • affected shows that the Atmos component's metadata section was changed
      (since the component is new and the metadata section is the first section that Atmos processes)

    • affected_all shows all the affected sections and attributes:

      • component - the Terraform component (Terraform configuration) was affected (since it was just added)
      • stack.metadata - the Atmos component's metadata section was changed
      • stack.vars - the Atmos component's vars section was changed
      • stack.env - the Atmos component's env section was changed
      • stack.settings - the Atmos component's settings section was changed
Add Atmos Validation Policy Execution Context. Update docs @aknysh (#1261)

what

  • Add Atmos Validation Policy Execution Context
  • Update docs
  • Add unit tests

why

Policy Execution Context

Atmos allows enforcing custom governance rules based on metadata about Atmos commands and provides a powerful
policy evaluation mechanism by passing structured metadata to OPA policies at runtime.

This metadata enables fine-grained control over when certain actions (like terraform apply) are allowed or denied,
based on the context in which they're executed.

Policy Metadata

When Atmos runs a command, it supplies an input object to OPA policies that contains detailed contextual information, such as:

  • cli_args: a list of the command line arguments and flags (e.g., executing the atmos terraform apply command will generate the ["terraform", "apply"] list)
  • vars: a map of variables passed to the command, either via the stack config files or CLI flags
  • other contextual attributes such as the stack and component names

Policy Execution Context Example

Below is an OPA policy rule to enforce infrastructure governance during command execution.
Specifically, this rule blocks the execution of atmos terraform apply if the variable foo is set to the string "foo".

# 'package atmos' is required in all Atmos OPA policies
package atmos

# Atmos looks for the 'errors' (array of strings) output from all OPA policies
# If the 'errors' output contains one or more error messages, Atmos considers the policy failed

# Don't allow `terraform apply` if the `foo` variable is set to `foo`
# The `input` map contains the `cli_args` attribute (a list of the command line arguments and flags)
errors[message] {
    count(input.cli_args) >= 2
    input.cli_args[0] == "terraform"
    input.cli_args[1] == "apply"
    input.vars.foo == "foo"
    message = "the component can't be applied if the 'foo' variable is set to 'foo'"
}

The rule checks if:

  • The cli_args list has at least two items
  • The command (first item in the cli_args list) is terraform
  • The subcommand (second item in the cli_args list) is apply
  • The variable foo is set to "foo"

If all conditions are true, the rule generates an error message.

The generated error message is added to the errors array.
Atmos interprets the presence of any messages in errors as a policy violation and blocks the operation with the
following error:

the component can't be applied if the 'foo' variable is set to 'foo'

exit status 1
[Stores] Add user-managed replication support to GSM @ohaibbq (#1260)

what

  • Add support for user-managed replication locations to the Google Secret Manager store

why

  • GCP projects often have policies that constrain where resources are physically located
Update `stacks.name_template`. Update docs @aknysh (#1264)

what

  • Update stacks.name_template
  • Update docs
  • Add unit tests

why

For the remote-state terraform module and terraform-provider-utils, allow using the stacks.name_template setting in atmos.yaml with a limited context:

  • .vars.namespace
  • .vars.tenant
  • .vars.environment
  • .vars.stage
name_template: "{{.vars.tenant}}-{{.vars.environment}}-{{.vars.stage}}"

This will allow using name_template (instead of name_pattern) in both Atmos CLI and the remote-state module (to get the outputs of TF components)

stacks.name_template serves the same purpose as stacks.name_pattern (defines the naming convention for the top-level Atmos stacks), but provides much more functionality. Instead of using the predefined context variables as tokens, it uses Go templates.

Atmos Template Functions, Sprig Functions, Gomplate Functions, and Gomplate Datasources are supported as well

name_template can have complex logic and use template expressions and functions. The following template defines a name_template that builds a stack_name string by validating and concatenating several input variables in a hierarchical order.

name_template: |-
  {{- $ns := .vars.namespace -}}
  {{- $tenant := .vars.tenant -}}
  {{- $env := .vars.environment -}}
  {{- $stage := .vars.stage -}}
  {{- $stack_name := "" -}}

  {{- if eq $ns "" -}}
  {{- fail "Error: 'namespace' is required." -}}
  {{- end -}}

  {{- if and (ne $tenant "") (eq $ns "") -}}
  {{- fail "Error: 'tenant' requires 'namespace'." -}}
  {{- end -}}

  {{- if and (ne $env "") (or (eq $tenant "") (eq $ns "")) -}}
  {{- fail "Error: 'environment' requires 'tenant' and 'namespace'." -}}
  {{- end -}}

  {{- if and (ne $stage "") (or (eq $env "") (eq $tenant "") (eq $ns "")) -}}
  {{- fail "Error: 'stage' requires 'environment', 'tenant', and 'namespace'." -}}
  {{- end -}}

  {{- if ne $tenant "" -}}
  {{- $stack_name = $tenant -}}
  {{- end -}}

  {{- if ne $env "" -}}
  {{- $stack_name = printf "%s-%s" $stack_name $env -}}
  {{- end -}}

  {{- if ne $stage "" -}}
  {{- $stack_name = printf "%s-%s" $stack_name $stage -}}
  {{- end -}}

  {{- $stack_name -}}

It pulls values from the Atmos section vars and assigns them to local template variables:

  • namespace
  • tenant
  • environment
  • stage

The template enforces hierarchical dependencies between variables:

  • namespace is required
  • If tenant is provided, namespace must also be set
  • If environment is provided, both tenant and namespace must be set
  • If stage is provided, then environment, tenant, and namespace must all be set

If validations pass, it constructs the stack_name progressively:

  • Starts with tenant if it exists
  • Appends environment if it exists
  • Appends stage if it exists

The template outputs the resulting stack name. For example, if the variables are:

namespace: acme
tenant: plat
environment: ue2
stage: prod

The resulting stack name will be plat-ue2-prod.

Contributors

ohaibbq and aknysh
Loading

v1.177.0-rc.0

24 May 01:04
@cloudposse-releaser cloudposse-releaser
v1.177.0-rc.0
1953e23
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.177.0-rc.0 Pre-release
Pre-release
Add Atmos Validation Policy Execution Context. Update docs @aknysh (#1261) ## what
  • Add Atmos Validation Policy Execution Context
  • Update docs
  • Add unit tests

why

Policy Execution Context

Atmos allows enforcing custom governance rules based on metadata about Atmos commands and provides a powerful
policy evaluation mechanism by passing structured metadata to OPA policies at runtime.

This metadata enables fine-grained control over when certain actions (like terraform apply) are allowed or denied,
based on the context in which they're executed.

Policy Metadata

When Atmos runs a command, it supplies an input object to OPA policies that contains detailed contextual information, such as:

  • cli_args: a list of the command line arguments and flags (e.g., executing the atmos terraform apply command will generate the ["terraform", "apply"] list)
  • vars: a map of variables passed to the command, either via the stack config files or CLI flags
  • other contextual attributes such as the stack and component names

Policy Execution Context Example

Below is an OPA policy rule to enforce infrastructure governance during command execution.
Specifically, this rule blocks the execution of atmos terraform apply if the variable foo is set to the string "foo".

# 'package atmos' is required in all Atmos OPA policies
package atmos

# Atmos looks for the 'errors' (array of strings) output from all OPA policies
# If the 'errors' output contains one or more error messages, Atmos considers the policy failed

# Don't allow `terraform apply` if the `foo` variable is set to `foo`
# The `input` map contains the `cli_args` attribute (a list of the command line arguments and flags)
errors[message] {
    count(input.cli_args) >= 2
    input.cli_args[0] == "terraform"
    input.cli_args[1] == "apply"
    input.vars.foo == "foo"
    message = "the component can't be applied if the 'foo' variable is set to 'foo'"
}

The rule checks if:

  • The cli_args list has at least two items
  • The command (first item in the cli_args list) is terraform
  • The subcommand (second item in the cli_args list) is apply
  • The variable foo is set to "foo"

If all conditions are true, the rule generates an error message.

The generated error message is added to the errors array.
Atmos interprets the presence of any messages in errors as a policy violation and blocks the operation with the
following error:

the component can't be applied if the 'foo' variable is set to 'foo'

exit status 1

Summary by CodeRabbit

  • New Features
    • Added support for passing CLI arguments context to validation policies, enabling advanced policy enforcement based on command-line input.
    • Introduced new test scenarios and configuration files for stack validation using Open Policy Agent (OPA) policies.
  • Bug Fixes
    • Improved handling and filtering of CLI arguments to ensure accurate context is provided to validation logic.
  • Documentation
    • Added detailed documentation on policy execution context for OPA integration.
    • Updated CLI command documentation metadata and integration guides.
  • Tests
    • Added new tests for stack validation and describe stacks command execution.
  • Chores
    • Upgraded Atmos version to 1.177.0 in relevant configurations.
    • Removed obsolete debugging statements and improved code comments.
[Stores] Add user-managed replication support to GSM @ohaibbq (#1260) ## what

Adds support for user-managed replication locations to the Google Secret Manager store

why

Cloud projects often have policies that constrain where resources are physically located

Summary by CodeRabbit

  • New Features

    • Added support for specifying secret replication locations when creating secrets, allowing choice between automatic and user-managed replication.

  • Tests

    • Enhanced tests to cover both automatic and user-managed replication scenarios for secret creation.
Update `stacks.name_template`. Update docs @aknysh (#1264) ## what
  • Update stacks.name_template
  • Update docs
  • Add unit tests

why

For the remote-state terraform module and terraform-provider-utils, allow using the stacks.name_template setting in atmos.yaml with a limited context:

  • .vars.namespace
  • .vars.tenant
  • .vars.environment
  • .vars.stage
name_template: "{{.vars.tenant}}-{{.vars.environment}}-{{.vars.stage}}"

This will allow using name_template (instead of name_pattern) in both Atmos CLI and the remote-state module (to get the outputs of TF components)

stacks.name_template serves the same purpose as stacks.name_pattern (defines the naming convention for the top-level Atmos stacks), but provides much more functionality. Instead of using the predefined context variables as tokens, it uses Go templates.

Atmos Template Functions, Sprig Functions, Gomplate Functions, and Gomplate Datasources are supported as well

name_template can have complex logic and use template expressions and functions. The following template defines a name_template that builds a stack_name string by validating and concatenating several input variables in a hierarchical order.

name_template: |-
  {{- $ns := .vars.namespace -}}
  {{- $tenant := .vars.tenant -}}
  {{- $env := .vars.environment -}}
  {{- $stage := .vars.stage -}}
  {{- $stack_name := "" -}}

  {{- if eq $ns "" -}}
  {{- fail "Error: 'namespace' is required." -}}
  {{- end -}}

  {{- if and (ne $tenant "") (eq $ns "") -}}
  {{- fail "Error: 'tenant' requires 'namespace'." -}}
  {{- end -}}

  {{- if and (ne $env "") (or (eq $tenant "") (eq $ns "")) -}}
  {{- fail "Error: 'environment' requires 'tenant' and 'namespace'." -}}
  {{- end -}}

  {{- if and (ne $stage "") (or (eq $env "") (eq $tenant "") (eq $ns "")) -}}
  {{- fail "Error: 'stage' requires 'environment', 'tenant', and 'namespace'." -}}
  {{- end -}}

  {{- if ne $tenant "" -}}
  {{- $stack_name = $tenant -}}
  {{- end -}}

  {{- if ne $env "" -}}
  {{- $stack_name = printf "%s-%s" $stack_name $env -}}
  {{- end -}}

  {{- if ne $stage "" -}}
  {{- $stack_name = printf "%s-%s" $stack_name $stage -}}
  {{- end -}}

  {{- $stack_name -}}

It pulls values from the Atmos section vars and assigns them to local template variables:

  • namespace
  • tenant
  • environment
  • stage

The template enforces hierarchical dependencies between variables:

  • namespace is required
  • If tenant is provided, namespace must also be set
  • If environment is provided, both tenant and namespace must be set
  • If stage is provided, then environment, tenant, and namespace must all be set

If validations pass, it constructs the stack_name progressively:

  • Starts with tenant if it exists
  • Appends environment if it exists
  • Appends stage if it exists

The template outputs the resulting stack name. For example, if the variables are:

namespace: acme
tenant: plat
environment: ue2
stage: prod

The resulting stack name will be plat-ue2-prod.

Summary by CodeRabbit

  • New Features
    • Added support for stack name templates, allowing flexible and hierarchical stack naming using Go templates and context variables.
  • Bug Fixes
    • Improved error handling when both stack name template and pattern are missing.
  • Documentation
    • Expanded documentation with detailed examples and guidance for stack name templates and supported template functions.
  • Tests
    • Introduced new tests and configuration scenarios to validate stack name templating functionality.
  • Chores
    • Upgraded several dependencies to their latest versions for improved stability and compatibility.

Contributors

ohaibbq and aknysh
Loading

v1.176.0

20 May 01:16
@cloudposse-releaser cloudposse-releaser
v1.176.0
b6c2077
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.176.0
Update `overrides` section. Add tests @aknysh (#1259)

what

  • Update overrides section
  • Add tests

why

  • Improve the overrides section to detect and process the inline overrides in the imported stack manifests to allow the configurations like these:
vars:
  stage: prod

import:
  # The `overrides` is imported after the component `c1` is imported.
  # The `overrides` should not override anything for the component `c1`.
  - catalog/c1
  - catalog/overrides
vars:
  stage: prod

import:
  # The `overrides` is imported before the component `c1` is imported.
  # The `overrides` will override the component `c1` configuration.
  - catalog/overrides
  - catalog/c1
Configure YAML formatting in atmos describe commands @Cerebrovinny (#1180)

what

  • Make the indentation and empty components configurable trough atmos.yaml file

why

custom tab width: 4
Screenshot 2025-03-31 at 13 06 49

tab width: 2 (default config)
Screenshot 2025-03-31 at 13 07 12

Include Empty False (default config)
Screenshot 2025-03-31 at 13 07 42

# Atmos Describe Settings
describe:
  settings:
    include_empty: false

# Global settings
settings:
  terminal:
    tab_width: 4 # default should be 2
Add pager for `atmos describe component` @samtholiya (#1215)

what

  • Add pager for atmos describe component

why

  • Better UX
Custom columns docs @Cerebrovinny (#1219)

what

  • Add atmos list custom columns documentation

why

  • We have multiple places using custom columns in atmos list but are missing documentation
Implement `atmos list vendor` @Cerebrovinny (#1192)

what

  • Implement atmos list vendor command to list all vendor configurations in multiple formats (table, json, yaml, csv, tsv).
  • Implements filtering and custom columns.

why

  • Provides a way to view and audit all vendor configurations.

Screenshot 2025-04-15 at 18 34 00

Nested components for `atmos list vars` @Cerebrovinny (#1225)

what

  • Enabled atmos list vars and atmos list values to correctly display information for nested components (e.g., apis/weather, eks/cluster).

why

  • previously we assume and extract only the basename of nested components
  • These changes ensure the full component path is used for both existence checks and data querying.

Contributors

aknysh, samtholiya, and Cerebrovinny
Loading

v1.176.0-rc.2

20 May 01:05
@cloudposse-releaser cloudposse-releaser
v1.176.0-rc.2
b6c2077
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.176.0-rc.2 Pre-release
Pre-release
Update `overrides` section. Add tests @aknysh (#1259) ## what
  • Update overrides section
  • Add tests

why

  • Improve the overrides section to detect and process the inline overrides in the imported stack manifests to allow the configurations like these:
vars:
  stage: prod

import:
  # The `overrides` is imported after the component `c1` is imported.
  # The `overrides` should not override anything for the component `c1`.
  - catalog/c1
  - catalog/overrides
vars:
  stage: prod

import:
  # The `overrides` is imported before the component `c1` is imported.
  # The `overrides` will override the component `c1` configuration.
  - catalog/overrides
  - catalog/c1

Contributors

aknysh
Loading

v1.176.0-rc.1

17 May 01:03
@cloudposse-releaser cloudposse-releaser
v1.176.0-rc.1
050749c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.176.0-rc.1 Pre-release
Pre-release
Configure YAML formatting in atmos describe commands @Cerebrovinny (#1180) ## what

This PR makes the indentation and empty components configurable trough atmos.yaml file.

why

Evidence:
custom tab width: 4
Screenshot 2025-03-31 at 13 06 49

tab width: 2 (default config)
Screenshot 2025-03-31 at 13 07 12

Include Empty False (default config)
Screenshot 2025-03-31 at 13 07 42

# Atmos Describe Settings
describe:
  settings:
    include_empty: false

# Global settings
settings:
  terminal:
    tab_width: 4 # default should be 2

references

Summary by CodeRabbit

  • New Features

    • Added support for configurable YAML indentation in terminal output via a new tab_width setting.
    • Introduced a configuration option to control inclusion of empty sections in stack and component descriptions.
    • Enabled filtering of empty sections and empty string values from describe command outputs.

  • Improvements

    • Updated logging to use a structured logging library for clearer debug and info messages.
    • YAML and JSON output formatting now respects user-defined indentation settings and is more consistent.
    • Enhanced describe command output to conditionally exclude empty sections based on configuration.

  • Bug Fixes

    • Fixed handling of nil configuration pointers in YAML utilities to prevent errors.

  • Documentation

    • Updated documentation to include the new tab_width configuration option.

  • Tests

    • Added comprehensive tests for filtering empty sections, YAML output formatting, and new configuration options.
    • Added unit tests for empty section filtering logic and configuration retrieval functions.
add pager for describe component @samtholiya (#1215) ## what
  • We are adding pager to atmos describe component
  • We fixed the bug in the function that would assume the data is always atmosConfig and then use it to Highlight the data. This was all good if the data is atmosConfig but not for other cases.

image

why

  • We want user to give a consistent experience.

references

Summary by CodeRabbit

  • New Features
    • Introduced a pager option for the describe component command, enabling paged output with syntax highlighting for YAML and JSON formats.
    • Enhanced output formatting with customizable syntax highlighting based on user configuration.
  • Bug Fixes
    • Improved argument validation and error handling for CLI commands.
  • Documentation
    • Added documentation for the new --pager flag in the describe component command.
  • Tests
    • Added unit and integration tests covering pager functionality, output formatting, and CLI command execution.
  • Refactor
    • Refactored command execution and output handling for improved modularity, testability, and configuration management.
    • Updated output functions to accept configuration context for consistent formatting and highlighting.

Contributors

samtholiya and Cerebrovinny
Loading

v1.176.0-rc.0

16 May 01:05
@cloudposse-releaser cloudposse-releaser
v1.176.0-rc.0
a55467b
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.176.0-rc.0 Pre-release
Pre-release
Custom Columns docs @Cerebrovinny (#1219) ## what

atmos list custom columns documentation

why

We have multiple places using custom columns in atmos list but are missing documentation

references

Summary by CodeRabbit

  • Documentation
    • Added a comprehensive guide on customizing output columns for various atmos list commands, including detailed configuration examples and troubleshooting tips.
    • Introduced new sections with YAML configuration examples for customizing columns in list components, list stacks, list workflows, list metadata, list settings, list values, and list vars commands.
    • Expanded and clarified documentation to help users tailor command output to their needs.
atmos list vendor @Cerebrovinny (#1192) ## what
  • atmos list vendor command to list all vendor configurations in multiple formats (table, json, yaml, csv, tsv).
  • Implements filtering, custom columns.

why

  • Provides a way to view and audit all vendor configurations.

Evidence:
Screenshot 2025-04-15 at 18 34 00

references

Summary by CodeRabbit

  • New Features

    • Introduced a new CLI command to list vendor configurations with customizable output formats, stack filtering, and delimiter options.
    • Added support for displaying vendor configuration details in table, JSON, CSV, and TSV formats with customizable columns and headers.

  • Documentation

    • Added detailed usage documentation with examples for the new vendor listing command.

  • Bug Fixes

    • Enhanced error handling and validation during vendor configuration discovery and listing.

  • Tests

    • Added comprehensive tests covering vendor listing, filtering, formatting, manifest discovery, and error scenarios.

  • Refactor

    • Extended configuration schema and formatting options to support advanced vendor listing features.
Better Handle Empty Tables @Cerebrovinny (#1228) ## what

Identified issues when considering that the table is "empty"

why

Added full tests for utils and empty table cases
Making sure we validate the places where we are using these utils pkg and block future regressions

references

Summary by CodeRabbit

  • Bug Fixes

    • Improved output handling for metadata and settings listings, ensuring results are returned consistently without additional empty output checks or messages.

  • Tests

    • Added comprehensive unit tests for utility functions to verify component existence checks and error identification, covering various scenarios and edge cases.

🚀 Enhancements

Fix: nested components for list pkg @Cerebrovinny (#1225) ## what

Enabled atmos list vars and atmos list values to correctly display information for nested components (e.g., apis/weather, eks/cluster).

why
previously we assume and extract only the basename of nested components
These changes ensure the full component path is used for both existence checks and data querying.

references

Summary by CodeRabbit

  • Refactor
    • Added support for a new component type, enabling users to query both Terraform and Helmfile components.
    • Improved component value extraction with enhanced error handling and modular query construction for better reliability.
    • Expanded component existence checks to cover all component types, providing more comprehensive search results.
  • Tests
    • Introduced new tests to verify query expression construction across different component types and configurations.

Contributors

Cerebrovinny
Loading
0