v1.99.0

Update Atmos manifests validation JSON schema. Improve help for Atmos commands. Deep-merge the `settings.integrations.github` section from stack manifests with the `integrations.github` section from `atmos.yaml` @aknysh (#755)

what

• Update Atmos manifests validation JSON schema
• Improve help and error handling for Atmos commands
• Deep-merge the settings.integrations.github section from Atmos stack manifests with the integrations.github section from atmos.yaml

why

• In Atmos manifests validation JSON schema, don't "hardcode" the s3 backend section fields, allow it to be a free-form map so the user can define any configuration for it. The Terraform s3 backend can change, can be different for Terraform and OpenTofu. Also, the other backends (e.g. GCP, Azure, remote) are already free-form maps in the validation schema

• When Atmos commands are executed w/o specifying a component and a stack (e.g. atmos terraform plan, atmos terraform apply, atmos terraform clean), print help for the command w/o throwing errors that a component and stack are missing

• Deep-merging the settings.integrations.github section from Atmos stack manifests with the integrations.github section from atmos.yaml allows configuring the global settings for integrations.github in atmos.yaml, and then override them in the Atmos stack manifests in the settings.integrations.github section. Every component in every stack will get settings.integrations.github from atmos.yaml. You can override any field in stack manifests. Atmos deep-merges the integrations.github values from all scopes in the following order (from the lowest to highest priority):

  • integrations.github section from atmos.yaml
  • stack-level settings.integrations.github configured in Atmos stack manifests per Org, per tenant, per region, per account
  • base component(s) level settings.integrations.github section
  • component level settings.integrations.github section

  For example:

  atmos.yaml

  integrations:
    # GitHub integration
    github:
      gitops:
        opentofu-version: 1.8.4
        terraform-version: 1.9.8
        infracost-enabled: false

  stacks/catalog/vpc.yaml

  components:
    terraform:
      vpc:
        metadata:
          component: vpc
       settings:
         integrations:
           github:
             gitops:
               infracost-enabled: true
               test_enabled: true

  Having the above config, the command atmos describe component vpc -s tenant1-ue2-dev returns the following deep-merged configuration for the component's settings.integrations.github section:

  settings:
    integrations:
      github:
        gitops:
          infracost-enabled: true
          opentofu-version: 1.8.4
          terraform-version: 1.9.8
          test_enabled: true

Improve custom command error message for missing arguments @pkbhowmick (#752)

what

• Improved custom command error message for missing arguments including the name of argument for better user's understanding.

why

• If a custom command expects an argument, it should say so with the arguments name.

Fix helmfile demo @osterman (#753)

what

• Enable templates in atmos.yaml so we can use env function to get current work directory
• Do not default KUBECONFIG to /dev/shm as /dev/shm is a directory, and the kube config should be a YAML file
• Fix stack includes
• Set KUBECONFIG from components.helmfile.kubeconfig_path if set (previously only set if use_eks was true)

why

• Demo was not working

v1.98.0

Add `atmos docs ` command @RoseSecurity (#751)

what

• Add atmos docs <component> CLI command
• Render component documentation utilizing the atmos docs <component> command

why

• Improve user experience when navigating component documentation

testing

• Ensure existing functionality to the docs command is not affected
• Tested without valid Atmos Base Path
• Tested with nonexistent component name
• Tested with valid component name
• Tested with invalid component name
• Tested with nested component names

references

v1.97.0

Add support for remote validation schemas @haitham911 (#731)

What

• Add support for remote schemas in atmos for manifest validation
• Updated schemas configuration to allow referencing remote schema files, e.g.:

  schemas:
    atmos:
      manifest: "https://atmos.tools/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json"

Why

• This reduces redundancy, the schema file can be referenced remotely .

Do not process stack configs when executing command `atmos vendor pull` and the `--stack` flag is not specified @haitham911 (#740)

what

• Do not process stack configs when executing command atmos vendor pull and the --stack flag is not specified

why

• Atmos vendor should not require stack configs if the stack flag is not provided

v1.96.0

Set custom User Agent for Terraform providers @Cerebrovinny (#729)

What

• The Atmos command now sets the TF_APPEND_USER_AGENT environment variable, which Terraform uses when interacting with the AWS provider.
• Users can also append custom values to TF_APPEND_USER_AGENT, allowing further flexibility in monitoring or tracking specific operations.
• If no user-defined value is provided, the system will automatically set atmos {currentVersion} as the default.

Why

• Add a customer-specific user agent for Terraform operations. This enhancement ensures that Atmos-driven actions are identifiable and distinct from other operations.
• Users will be able to differentiate and monitor Atmos-initiated actions within AWS, facilitating better tracking, logging, and troubleshooting.

WIP: Document helmfile, template imports @osterman (#741)

what

• Document options for helmfile
• Update helmfile demo to use options
• Document versioning of components

Fix example demo-context @Cerebrovinny (#743)

what

• Running atmos in demo-context folder causes the code to process all stack configurations, including the catalog stacks

fix `atmos version` @haitham911 (#735)

what

• atmos version should work regardless if the stack configs are provided

v1.95.0

Do not process stack configs when executing command `atmos vendor pull` and the `stack` flag is not specified @haitham911 (#738)

what

• Do not process stack configs when executing command atmos vendor pull and the stack flag is not specified

why

• Atmos vendor should not require stack configs if the stack flag is not provided

v1.94.0

Updates to Installation Instructions @osterman (#549)

what

• Add terminal configuration instructions
• Add installation instructions for fonts

why

• Not everyone is familiar with what makes atmos TUI look good =)

Read Atmos config and vendor config from .yaml or .yml @haitham911 (#736)

what

• Read Atmos config and vendor file from atmos.yaml or atmos .yml, vendor.yaml or vendor.yml
• If both .yaml and .yml files exist, the .yaml file is prioritized

why

• Supports both YAML extensions

Improve logging in `atmos vendor pull` @haitham911 (#730)

What

• Added functionality to log the specific tags being processed during atmos vendor pull --tags demo.
• Now, when running the command, the log will display: Processing config file vendor.yaml for tags {demo1, demo2, demo3}.

Why

• This update improves visibility by explicitly showing the tags during the pull operation

v1.93.0

Fix: condition to display help interactive menu @Cerebrovinny (#724)

what

• Ensure that the usage is displayed only when invoking the help commands or when the help flag is set

why

• Running incorrect commands in Atmos caused the output to be an interactive help menu forcing the user to manually exit the UI

v1.92.0

Improve error handling @haitham911 (#726)

what

• Improve error handling , check log level Trace for detailed trace information

why

• Print detailed error only when log level Trace

Document vendoring from private git repos @osterman (#723)

what

• Document how to vendor from private GitHub repos
• Document template syntax for vendoring

why

• The syntax is a bit elusive, and it's a common requirement

v1.91.0

feat: support for `.yml` and `.yaml` file extensions for component vendoring @RoseSecurity (#725)

## what

• Support for .yml and .yaml when vendoring using component.yaml

why

• The tool is strict about needing component.yaml, file ending for yaml files is a matter of preference and both should be accepted.

testing

• make build

# component.yml
❯ ./build/atmos vendor pull -c aurora-postgres-resources
Pulling sources for the component 'aurora-postgres-resources' from 'github.com/cloudposse/terraform-aws-components.git//modules/aurora-postgres-resources?ref=1.511.0' into 
'/Users/infra/components/terraform/aurora-postgres-resources'

# component.yaml
❯ ./build/atmos vendor pull -c aurora-postgres-resources
Pulling sources for the component 'aurora-postgres-resources' from 'github.com/cloudposse/terraform-aws-components.git//modules/aurora-postgres-resources?ref=1.511.0' into 
'/Users/infra/components/terraform/aurora-postgres-resources'

# Missing both
❯ ./build/atmos vendor pull -c aurora-postgres-resources
component vendoring config file does not exist in the '/Users/infra/components/terraform/aurora-postgres-resources' folder

references

• Closes the following issue

Summary by CodeRabbit

Summary by CodeRabbit

• New Features

  • Enhanced file existence checks for component configuration, now supporting both .yaml and .yml file formats.

• Refactor

  • Streamlined variable declarations for improved readability without changing logic.

Add the guide to install atmos using aqua @suzuki-shunsuke (#720)

## what

Add the guide to install atmos using aqua.

why

aqua is a CLI Version Manager written in Go.
aqua supports various tools including atmos, Terraform, Helm, Helmfile.

Confirmation

I have launched the webserver on my laptop according to the guide.

references

Summary by CodeRabbit

• New Features

  • Introduced a new installation method for Atmos using the aqua CLI version manager.
  • Added a dedicated tab in the installation guide for aqua, including instructions for setup and usage.

• Documentation

  • Updated the "Install Atmos" document to enhance user guidance on installation options.

v1.90.0

Always template vendor source and targets @mss (#712)

## what

This change improves the templating within vendor manifests slightly: It officially adds support for the Component field to both source and targets.

These features were already supported but mostly undocumented and hidden behind an implicit switch: The templating was only triggered if the Version field was set. Which was also the only officially supported field.

In reality though all fields from the current source definition were available but in the state they were currently in, depending on the order of the templates.

With this change

• It is clearly documented which fields are supported in which YAML values.
• Only the two static fields are supported.
• The values are always templated.

Theoretically this could be a breaking change if somebody used no version field but curly braces in their paths. Or relied on the half-populated source data structure to refer to unsupported fields. If xkcd 1172 applies it should be possible to amend this logic to add more officially supported fields.

why

I was looking for a way to restructure our vendoring like the examples in examples/demo-vendoring/vendor.yaml to avoid copy and paste errors when we release new component versions.

I actually only found out about that demo when I was done writing this code since the templating was never triggered without a version field and the documentation didn't mention it.

references

• https://github.com/cloudposse/atmos/blob/v1.88.1/examples/demo-vendoring/vendor.yaml
• https://atmos.tools/core-concepts/vendor/vendor-manifest/#vendoring-manifest

Summary by CodeRabbit

• New Features

  • Enhanced vendoring configuration with support for dynamic component referencing in vendor.yaml.
  • Improved handling of source and targets attributes for better organization and flexibility.

• Documentation

  • Updated documentation for vendoring configuration, including clearer instructions and examples for managing multiple vendor manifests.
  • Added explanations for included_paths and excluded_paths attributes to improve understanding.

Fix a reference to an undefined output in GitHub Actions @suzuki-shunsuke (#718)

## what

1. Fix a reference to an undefined output in GitHub Actions.

https://github.com/cloudposse/atmos/blob/6439a64488856c461a9eb7a8f7adb30901080cef/.github/workflows/test.yml#L312

The step config is not found.
This bug was added in #612 .

• b53d696
• #612

2. Use a version variable for easier updates.

env:
  TERRAFORM_VERSION: "1.9.7"

steps:
  - uses: hashicorp/setup-terraform@v3
    with:
      terraform_version: ${{ env.TERRAFORM_VERSION }}

#717 (comment)

3. Stop installing terraform wrapper

By default hashicorp/setup-terraform installs a wrapper of Terraform to output Terraform stdout and stderr as step's outputs.
But we don't need them, so we shouldn't install the wrapper.

https://github.com/hashicorp/setup-terraform

- uses: hashicorp/setup-terraform@v3
  with:
    terraform_wrapper: false

why

references

Summary by CodeRabbit

• Chores
  • Updated workflow configurations for improved maintainability.
  • Introduced a new environment variable TERRAFORM_VERSION for version management.

ci: install Terraform to fix CI failure that Terraform is not found @suzuki-shunsuke (#717)

## what

Install Terraform using hashicorp/setup-terraform action in CI.

why

CI failed because Terraform wasn't found.

https://github.com/cloudposse/atmos/actions/runs/11307359580/job/31449045566
https://github.com/cloudposse/atmos/actions/runs/11307359580/job/31449046010

Run cd examples/demo-context
all stacks validated successfully
exec: "terraform": executable file not found in $PATH

This is because ubuntu-latest was updated to ubuntu-24.04 and Terraform was removed from it.

https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md

On the other hand, Ubuntu 22.04 has Terraform.

https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md

references

Summary by CodeRabbit

• Chores
  • Enhanced workflow for testing and linting by integrating Terraform setup in multiple job sections.
  • Updated the lint job to dynamically retrieve the Terraform version for improved flexibility.