v1.105.0

Clean Terraform workspace before executing `terraform init` in the `atmos.Component` template function @aknysh (#775)

what

• Clean Terraform workspace before executing terraform init in the atmos.Component template function

why

When using multiple backends for the same component (e.g. separate backends per tenant or account), and if an Atmos command was executed that selected a Terraform workspace, Terraform will prompt the user to select one of the following workspaces:

 1. default
 2. <the previously used workspace>

The prompt forces the user to always make a selection (which is error-prone), and also makes it complicated when running on CI/CD.

This PR adds the logic that deletes the .terraform/environment file from the component directory before executing terraform init when executing the atmos.Component template function. It allows executing the atmos.Component function for a component in different Terraform workspaces without Terraform asking to select a workspace. The .terraform/environment file contains the name of the currently selected workspace, helping Terraform identify the active workspace context for managing your infrastructure.

v1.104.0

Change PS1 to show that Atmos is in the `atmos terraform shell` mode @pkbhowmick (#761)

what

• Change PS1 to show that Atmos is in the atmos terraform shell mode
• Customized command prompt for the interactive shell with the addition of the "atmos>" prefix
• Enhanced shell behavior by removing the unnecessary -l flag for non-Windows systems and implementing a fallback to sh if bash is unavailable.
• Improved handling for the /bin/zsh shell with additional flags

why

• Improve user experience

test

v1.103.0

feat: additional `atmos docs` parameters for specifying width, using auto-styling and color profile, and preserving new lines @RoseSecurity (#757)

what

• Add an additional atmos docs flag for specifying the width of markdown output
• Utilizing auto-styling based on light or dark mode preferences instead of hardcoding to dark
• Preserving new lines with rendered markdown

why

• Enhance the user experience for interacting with documentation. The width parameter is useful for users who prefer seeing wider output for Terraform docs-generated tables and is defined in the atmos.yaml:

settings:
  docs:
    max-width: 200

references

• glow docs

v1.102.0

Wrapper for long lines in help @Cerebrovinny (#770)

what

• Implemented a new terminal-aware text wrapping system for CLI help output
• Added responsive width handling based on terminal size with fallback values
• Introduced custom usage template handling for consistent help text formatting
• Created dedicated terminal writer component for automatic text wrapping

why

• Improves readability of CLI help text by ensuring content fits within terminal width
• Provides better user experience with dynamic text wrapping based on terminal size
• Standardizes help text formatting across all commands
• Fixes potential issues with text overflow in narrow terminal windows

references

Before:

After:

v1.101.0

Skip component if `metadata.enabled` is set to `false` @pkbhowmick (#756)

what

• Skip component if metadata.enabled is set to false
• Added documentation on using the metadata.enabled parameter to conditionally exclude components in deployment

why

• Allow disabling Atmos components from being processed and provisioned by setting metadata.enabled to false in the stack manifest w/o affecting/changing/disabling the Terraform components (e.g. w/o setting the enabled variable to false)

demo

v1.100.1

Add .coderabbit.yaml for CodeRabbit integration configuration settings @osterman (#758)

what

• Add coderrabit config
• Tune the prompt
• Enable linear integration

why

• Want to work towards a config that is less noisy (although this is probably not the PR that solves that)

🚀 Enhancements

handle invalid command error @pkbhowmick (#766)

what

• Improved error handling for command arguments, providing clearer feedback when invalid commands are used
• Enhanced logging to include a list of available commands when an error occurs due to invalid arguments.

why

• Better user experience

working example

Before:

After fix:

v1.100.0

Improve `terraform` and `helmfile` help. Enable `Go` templating in the `command` field. Clean Terraform workspace before executing `terraform init` @aknysh (#759)

what

• Improve terraform and helmfile help
• Enable Go templating in the command field of stack config
• Clean Terraform workspace before executing terraform init

why

• Improve the help messages. When a user executes atmos terraform --help or atmos helmfile --help (or help for a subcommand), print a message describing the command and how to execute the terraform and helmfile help command

   atmos terraform --help

• Enable Go templating in the command stack config in addition to the already supported sections.

  You can now use Go templates in the following Atmos sections to refer to values in the same or other sections:

  • vars
  • settings
  • env
  • providers
  • overrides
  • backend
  • backend_type
  • component
  • metadata.component
  • command

  Enabling Go templates in the command section allows specifying different Terraform/OpenTofu/Helmfile versions per component/stack, and get the value from different Atmos sections or from external data sources

• Clean Terraform workspace before executing terraform init. When using multiple backends for the same component (e.g. separate backends per tenant or account), and if an Atmos command was executed that selected a Terraform workspace, Terraform will prompt the user to select one of the following workspaces:

   1. default
   2. <the previously used workspace>

  The prompt forces the user to always make a selection (which is error-prone), and also makes it complicated when running on CI/CD.

  The PR adds the logic that deletes the .terraform/environment file from the component directory before executing terraform init. The .terraform/environment file contains the name of the currently selected workspace, helping Terraform identify the active workspace context for managing your infrastructure. We delete the file before executing terraform init to prevent the Terraform prompt asking to select the default or the previously used workspace.

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