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

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