v1.126.0

Add support for `atmos terraform version` command @samtholiya (#846)

what

• Add support for atmos terraform version command

Add support for `atmos helmfile version` command @samtholiya (#854)

what

• Add support for atmos helmfile version command

Append new lines to end of the generated JSON files @joshAtRula (#849)

what

• Append new lines to end of the generated JSON files

why

• Better support for linting and pre-comming standards
• It's common for linters and pre-commit hooks to expect new lines at the end of files. In the case of the pretty-printed JSON (used for the creation of the backend.tf.json files) these objects are now properly indented, but still were lacking the new line at the end of the file

v1.125.0

Exclude abstract and disabled components from showing in the Atmos TUI @samtholiya (#851)

what

• Exclude abstract and disabled components from showing in the Atmos TUI

why

• Abstract and disabled components are not deployable

description

Suppose we have the following Atmos stack manifest:

# yaml-language-server: $schema=https://atmos.tools/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json

components:
  terraform:
    station:
      metadata:
        component: weather
      vars:
        location: Los Angeles
        lang: en
        format: ''
        options: '0'
        units: m
    station_disabled:
      metadata:
        component: weather
        enabled: false
      vars:
        location: Los Angeles
        lang: en
        format: ''
        options: '0'
        units: m
    station_abstract:
      metadata:
        component: weather
        type: abstract
      vars:
        location: Los Angeles
        lang: en
        format: ''
        options: '0'
        units: m

We would get the following in the Atmos TUI:

Now we get only the station component (the abstract and disabled components are excluded):

v1.124.0

Add pagination and searching to `atmos docs` command @RoseSecurity (#848)

what

• Add pagination and searching to atmos docs command
• Update website documentation to incorporate new CLI settings

why

• Enhance the user experience by making it possible to paginate and search component documentation

references

• Paging Output Implementation Reference

v1.123.1

🚀 Enhancements

`atmos terraform show` command should not delete Terraform planfiles @samtholiya (#855)

what

• atmos terraform show command should not delete Terraform planfiles

why

• We should not delete the terraform plan file when the user executes atmos terraform show command

v1.123.0

Dynamic width terminal calculation for `atmos --help` @Cerebrovinny (#815)

what

• Help should detect proper screen width

why

• Terminal Width should be dynamic calculated when the user prints help

[workflows] Fix preview deployment inactivation @goruha (#843)

what

• Deactivate preview env deployment only for the current branch

why

• Allow to have deployment per PR

Update Atmos stack manifest JSON schema. Fix docs @aknysh (#842)

what

• Update Atmos stack manifest JSON schema
• Fix docs

why

• Add the new attribute metadata.enabled to the Atmos stack manifest validation schema
• Fix some typos in the docs

Fix deployments overrides @goruha (#841)

what

• Fix deployments overrides

why

• Allow each PR to have independent preview env deployment

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