v1.122.0

Ignore template files when executing `atmos validate stacks` @Cerebrovinny (#830)

what

• Ignore template files when executing atmos validate stacks (exclude template files .yaml.tmpl, .yml.tmpl, .tmpl from being validated)
• Update documentation to clarify template file handling behavior

why

• Some template files are not valid YAML files, and should not be validated before processing the templates
• Preserve backward compatibility for existing configurations that previously used .tmpl stack manifest files

Refactor preview deployments workflows @goruha (#836)

what

• Decouple website-deploy-preview deployment workflow to website-preview-build and website-preview-deploy workflows
• Renamed website-destroy-preview workflow to website-preview-destroy
• Inactivate GitHub deployment on preview destroy workflow

why

• Support preview environment deployments for PRs from forks
• Follow workflow naming consistency
• Support cleaning up environments on preview destroy

v1.121.0

Imports for `overrides` @aknysh (#831)

what

• Allow importing stack manifests with the overrides sections
• Update docs
  • https://atmos.tools/core-concepts/stacks/overrides
  • https://atmos.tools/core-concepts/stacks/overrides/#importing-the-overrides

why

• To make the overrides configuration DRY and reusable, you can place the overrides sections into a separate stack manifest, and then import it into other stacks

For example:

Define the overrides sections in a separate manifest stacks/teams/testing-overrides.yaml:

# Global overrides
# Override the variables, env, command and settings ONLY in the components managed by the `testing` Team.
overrides:
  env:
    # This ENV variable will be added or overridden in all the components managed by the `testing` Team
    TEST_ENV_VAR1: "test-env-var1-overridden"
  settings: {}
  vars: {}

# Terraform overrides
# Override the variables, env, command and settings ONLY in the Terraform components managed by the `testing` Team.
# The Terraform `overrides` are deep-merged with the global `overrides`
# and takes higher priority (it will override the same keys from the global `overrides`).
terraform:
  overrides:
    settings:
      spacelift:
        # All the components managed by the `testing` Team will have the Spacelift stacks auto-applied
        # if the planning phase was successful and there are no plan policy warnings
        # https://docs.spacelift.io/concepts/stack/stack-settings#autodeploy
        autodeploy: true
    vars:
      # This variable will be added or overridden in all the Terraform components managed by the `testing` Team
      test_1: 1
    # The `testing` Team uses `tofu` instead of `terraform`
    # https://opentofu.org
    # The commands `atmos terraform <sub-command> ...` will execute the `tofu` binary
    command: tofu

Import the stacks/teams/testing-overrides.yaml manifest into the stack stacks/teams/testing.yaml:

import:
  # The `testing` Team manages all the components defined in this stack manifest and imported from the catalog
  - catalog/terraform/test-component-2
  # The `overrides` in `teams/testing-overrides` will affect all the components in this stack manifest
  # and all the components that are imported AFTER the `overrides` from `teams/testing-overrides`.
  # It will affect the components imported from `catalog/terraform/test-component-2`.
  # The `overrides` defined in this manifest will affect all the imported components, including `catalog/terraform/test-component-2`.
  - teams/testing-overrides
  - catalog/terraform/test-component
  - catalog/terraform/test-component-override

# The `overrides` in this stack manifest take precedence over the `overrides` imported from `teams/testing-overrides`

# Global overrides
# Override the variables, env, command and settings ONLY in the components managed by the `testing` Team.
overrides:
  env:
    # This ENV variable will be added or overridden in all the components managed by the `testing` Team
    TEST_ENV_VAR1: "test-env-var1-overridden-2"
  settings: {}
  vars: {}

# Terraform overrides
# Override the variables, env, command and settings ONLY in the Terraform components managed by the `testing` Team.
# The Terraform `overrides` are deep-merged with the global `overrides`
# and takes higher priority (it will override the same keys from the global `overrides`).
terraform:
  overrides:
    vars:
      # This variable will be added or overridden in all the Terraform components managed by the `testing` Team
      test_1: 2

NOTES:

• The order of the imports is important. The overrides in teams/testing-overrides will affect all the components in
  this stack manifest and all the components that are imported after the overrides from teams/testing-overrides.
  In other words, the overrides in teams/testing-overrides will be applied to the catalog/terraform/test-component
  and catalog/terraform/test-component-override components, but not to catalog/terraform/test-component-2

• On the other hand, the overrides defined in this stack manifest stacks/teams/testing.yaml will be applied to all
  components defined inline in stacks/teams/testing.yaml and all the imported components, including catalog/terraform/test-component-2

• The overrides defined inline in the stack manifest stacks/teams/testing.yaml take precedence over the overrides
  imported from teams/testing-overrides (they will override the same values defined in teams/testing-overrides)

v1.120.0

Export configuration information in shell launched by Atmos @Nuru (#827)

what

• Export Atmos Terraform configuration information in shell launched by Atmos

why

• When Atmos launches a shell, it configures the shell for Terraform to reference a certain component and stack. The configuration is such that Terraform commands will work with a specific component and stack when run from a specific directory, and that informations is output to the user, but it has not been available in the environment for scripts or other automation to reference. By exposing that information in the environment, tools (e.g. the command prompt) can notify the user of the invisible state information and also warn the user if they are executing commands from the wrong directory and help them get back to the right one, among other possibilities.

• Some commands, like atmos terraform shell, spawn an interactive shell with certain environment variables set, in order to enable the user to use other tools (in the case of atmos terraform shell, the Terraform or Tofu CLI) natively, while still being configured for a specific component and stack. To accomplish this, and to provide visibility and context to the user regarding the configuration, Atmos sets the following environment variables in the spawned shell

Variable	Description
ATMOS_COMPONENT	The name of the active component
ATMOS_SHELL_WORKING_DIR	The directory from which native commands should be run
ATMOS_SHLVL	The depth of Atmos shell nesting. When present, it indicates that the shell has been spawned by Atmos.
ATMOS_STACK	The name of the active stack
ATMOS_TERRAFORM_WORKSPACE	The name of the Terraform workspace in which Terraform comamnds should be run
PS1	When a custom shell prompt has been configured in Atmos, the prompt will be set via PS1
TF_CLI_ARGS_*	Terraform CLI arguments to be passed to Terraform commands

v1.119.0

Any usage of `--help` should not require stack configurations @Listener430 (#825)

what

• All help commands (using the --help flag) should not require stack configurations

why

• We need to show help message and version/upgrade information irrespective if stack configs are in place or not

fix: Cut release only when all tests passed @goruha (#721)

what

• Run release job only if all tests passed

why

• Do not release failed binaries

fix: typo @jedwardsCTL (#819)

what

• Fixes a minor grammar error

v1.118.0

Enable `Go` templates in `metadata.terraform_workspace` section @aknysh (#823)

what

• Enable Go templates in metadata.terraform_workspace and metadata.terraform_workspace_template sections

why

• Allow using Go templates to dynamically construct Terraform workspaces for Atmos components

components:
  terraform:
    test:
      metadata:
        # Point to the Terraform component
        component: "test"
        # Override Terraform workspace using `Go` templates
        terraform_workspace: '{{ .vars.tenant }}-{{ .vars.environment }}-{{ .vars.stage }}-test'

Upload build preview site as artifacts @goruha (#822)

what

• Upload preview site static files as GitHub actions artifacts

why

• This is the first step of preview deployment strategy refactoring to support preview deployments from forks

v1.117.0

Add Support for Automatic Templated File Search for Atmos Imports @Cerebrovinny (#795)

what

• Add Support for Automatic Templated File Search for Atmos Imports
• Automatic detection and import of templated files (.yaml.tmpl or .yml.tmpl) in Atmos

why

• Simplify import configuration by removing the need to explicitly specify .tmpl extensions
• Improve developer experience by reducing manual configuration overhead

v1.116.0

Show failed command and how to resume after `atmos workflow` failure @Cerebrovinny (#767)

What

• Show failed command and how to resume after atmos workflow failure
• Added improved workflow failure handling with clear error messages
• Added documentation and help text for workflow failure handling
• Added example workflow demonstrating failure scenarios

Why

• Makes it easier to debug and fix workflow failures by showing:
  • Which step failed
  • The exact command that failed
  • How to resume from the failed step
• Saves time by allowing users to resume workflows from failed steps instead of restarting from beginning
• Improves user experience with clear guidance on how to recover from failures

Tests

Example workflow demonstrating the feature:

workflows:

  test-1:
    description: "Test workflow with intentionally failing steps"
    steps:
      - name: "step-1"
        type: shell
        command: "echo 'This step will succeed' && exit 0"
      
      - name: "step-2"
        type: shell
        command: "echo 'This step will fail' && exit 1"
      
      - name: "step-3"
        type: shell
        command: "echo 'This step should not execute'"

When step-2 fails, users will see:

v1.115.0

Add custom help message and Atmos upgrade notification @Listener430 (#809)

what

• Enhance the Atmos CLI by adding a bordered update notification message at the bottom of the help output for all commands, including atmos --help and subcommands like atmos terraform --help. The update notification informs users if a newer version of atmos is available

why

• Prompts users to upgrade
• The bordered message is more noticeable

v1.114.0

Add `--everything` and `--force` flags to the `atmos terraform clean` command @haitham911 (#727)

What

• Add --everything and --force flags to the atmos terraform clean command to delete the Terraform-related folders and files, including:
  • backend.tf.json
  • .terraform
  • terraform.tfstate.d
  • .terraform.lock.hcl

The following scenarios are covered:

1. If no component is specified:
   atmos terraform clean --everything deletes all state files for all Terraform components and requires a confirmation from the user
   atmos terraform clean --everything --force deletes all state files for all Terraform components without a confirmation from the user

2. If a specific component is specified:
   atmos terraform clean <component> --everything - deletes the state files for the specified component

3. If both a component and a stack are specified:
   atmos terraform clean <component> --stack<stack> --everything - deletes the state files for the specified component and stack

Why

• Cleaning state files is useful when running tests (it should not be the default behavior to avoid unintended data loss)

Usage

atmos terraform clean <component> -s <stack> [--skip-lock-file] [--everything] [--force]

v1.113.0

Add `bool` flags to Atmos custom commands @pkbhowmick (#807)

what

• Add bool flags to Atmos custom commands

why

• Atmos custom commands supported only flags of type string