v1.162.1

Update `atmos terraform` commands that require processing of `Go` templates and Atmos YAML functions @aknysh (#1062)

what

• Update atmos terraform commands that require processing of Go templates and Atmos YAML functions

why

• The following atmos terraform commands require processing of Go templates and Atmos YAML functions in Atmos manifests:

plan
apply
deploy
destroy
generate
output
shell
write
force-unlock
import
refresh
show
taint
untaint
validate
state list
state mv
state pull
state push
state replace-provider
state rm
state show

related

• https://github.com/cloudposse/atmos/releases/edit/v1.160.0

v1.162.0

Improve Atmos help @samtholiya @aknysh (#959)

what

• Improve Atmos help

why

• Outputting markdown in help descriptions makes it easier to visually parse
• Markdown stylesheet keeps formatting consistent

examples

• atmos about non-existent shows usage:
  

• Double dash in flags of atmos terraform --help and examples rendering using markdown if available
  

• Fixed atmos workflow --file example.yaml markdown. Now it also exits with exit code 1
  

• Updated Default error logger with markdown support
  

• Added custom alias help support so that alias in config should also be displayed in help
  

• Updated the workflow name invalid UI
  

• Invalid custom command config now shows better help
  

• Invalid flag usage added
  

v1.161.0

Add tab completion for `components` and `stack` in Atmos commands @samtholiya (#992)

what

• Add tab completion for components and stack in Atmos commands
• Update docs https://atmos.tools/cli/commands/completion

why

• Providing completions for components and stack will improve the accuracy and speed of the user while executing commands that require components and stacks

Don't check stacks config in `atmos.yaml` in Atmos commands that don't require stacks @samtholiya (#1052)

what

• Don't check stacks config in atmos.yaml in Atmos commands that don't require stacks

why

• Atmos commands (including Atmos custom commands) may or may not be using components and stacks

Add Test Timeouts and Clean Working & Home Directories @osterman (#1051)

what

• Add a new timeout configuration to abort long running tests
• Disable version checks on tests that are not testing that functionality
• Change home directory to empty temp directory

why

• It's hard to identify sometimes which test is hung in CI; adding a timer makes it easier to track down
• Atmos and terraform orphan files (e.g. cache files) which means test behavior can change between runs
• Home directory configuration can affect test outcomes

Fix mergify dispatch @osterman (#1059)

what

• Incorrect specification of head ref

why

• Mergify doesn't really explain how to do it.
• Based on the example of how {{ author }} works, there's no pull_request prefix https://docs.mergify.com/workflow/actions/github_actions/#examples
• Based on the documentation here, it suggests the key is just head https://docs.mergify.com/configuration/data-types/#template

Documented Example

Based on the documentation,

The dynamic_workflow.yaml takes the template input author.

This implies that everything under data-types can be used as a Jinja template variable. Since author works (at least based on their example), head should as well.

pull_request_rules:
  - name: Dispatch GitHub Actions
    conditions:
      - label = dispatch
    actions:
      github_actions:
        workflow:
          dispatch:
            - workflow: foo_workflow.yaml
            - workflow: hello_world_workflow.yaml
              inputs:
                name: steve
                age: 42
            - workflow: dynamic_workflow.yaml
              inputs:
                author: "{{ author }}"

Support Trailing Args for Custom Commands @samtholiya (#1046)

what

• Add support for double dash -- argument in custom command
• Use {{ .TrailingArgs }} in templates to get the arguments after the double dash --
• Update docs

why

• Allow users use double dash -- to get the native args and send them to the custom command executable

Trailing Arguments

Atmos supports trailing arguments after -- (a standalone double-dash). The -- itself is a delimiter that signals the end of Atmos-specific options. Anything after -- is passed directly to the underlying command without being interpreted by Atmos. The value of these trailing arguments is accessible in {{ .TrailingArgs }}.

For the example, adding the following to atmos.yaml will introduce a new echo command that accepts one name argument and also uses trailingArgs

- name: ansible run
  description: "Runs an Ansible playbook, allowing extra arguments after --."
  arguments:
    - name: playbook
      description: "The Ansible playbook to run"
      default: site.yml
      required: true
  steps:
    - "ansible-playbook {{ .Arguments.playbook }} {{ .TrailingArgs }}"

Output:

$ atmos ansible run -- --limit web
Running: ansible-playbook site.yml --limit web

PLAY [web] *********************************************************************

v1.160.5

Update JSON schema for Atmos manifests validation. Update `!terraform.output` YAML function @aknysh (#1053)

what

• Update JSON schema for Atmos manifests validation. Add hooks to the JSON schema for Atmos manifests validation

• Update !terraform.output YAML function

why

• hooks is a recent addition to Atmos and need to be added to the JSON schema

• When executing !terraform.output, Atmos sets all the ENV variables from the parent process (that executes the CLI command) in the child process (that executes terraform output using the terraform-exec library. The library does not allow certain environment variables to be set in the process, so we don't include those

Add logging defaults @mcalhoun (#1050)

what

• Add sane defaults for logging when not provided via atmos.yaml or args

why

• To ensure logging still works, even if not specified in config

Add a spinner for `atmos validate component` command @RoseSecurity (#1047)

what

• Add a spinner to the atmos validate component command

why

• It can be difficult to tell whether the command is hanging or actively running in the background for larger components

v1.160.4

Update YAML function `!terraform.output` @aknysh (#1048)

what

• Update YAML function !terraform.output

why

• When executing !terraform.output for a component that sets environment variables in the env section, set the environment variables from the env section in the child process, and also copy the parent process environment variables into the child process
• The parent process environment variables can affect the !terraform.output execution, e.g. finding a terraform binary in the PATH

v1.160.3

Update Atmos YAML functions @aknysh (#1038)

what

• Handle environment variables (set in the env section) when running !terraform.output and atmos.Component
• If TF_DATA_DIR environment variable is set, clear the correct environment folder when reseting Terraform workspaces
• Additional logging for handling errors in terraform output
• Refactor the spinner logic

why

• If the component referred in !terraform.output and atmos.Component functions sets environment variables (in the env section), set the environment variables in the process running !terraform.output and atmos.Component functions
• Correctly handle the TF_DATA_DIR environment variable when reseting Terraform workspaces in the !terraform.output and atmos.Component functions
• Additional logging for debugging
• Refactor the spinner logic - separate the spinner logic into reusable functions so it can be used in many commands

v1.160.2

🚀 Enhancements

Execute Atmos YAML functions when running the command `atmos terraform output` @aknysh (#1033)

what

• Execute Atmos YAML functions when running the command atmos terraform output

why

• atmos terraform output requires processing of YAML functions and Go templates

Fix log level priority @samtholiya (#1031)

what

• Fix log level priority flag > env > config

why

• This is what customer expects based on CLI standard

Properly handle `stdout`, `stderr`, and `null` @osterman (#1029)

what

• Handle /dev/stderr, /dev/stdout, and /dev/null with charmbracelet logger

why

• Moving to charmbracelet logger, we didn't properly handle common devices
• Logs should always go to stderr by default, so it doesn't mess up GitHub actions or commands that parse output

v1.160.1

fix(vendor): Remove excessive URL validation @mss (#1024)

what

• Removed some excessive URL validation which blocked valid URLs in vendor manifests

why

• The validation blocked shallow Git clones (and other features supported by go-getter)

v1.160.0

Process `Go` templates and Atmos YAML functions only when executing `atmos terraform` commands that require it @aknysh (#1023)

what

• Process Go templates and Atmos YAML functions only when executing atmos terraform commands that require it

why

• Only the following atmos terraform commands require processing of Go templates and Atmos YAML functions in Atmos manifests:

  • plan
  • apply
  • deploy
  • destroy
  • generate

• All other atmos terraform command don't need the outputs of the templates and functions (e.g. atmos terraform init or atmos terraform workspace)

• Speed up the commands execution

• Some YAML functions like !terraform.output require assuming roles, and not executing it simplifies CI/CD workflows

v1.159.0

fix typo in Redis store error message @mcalhoun (#1022)

## what - Fixed environment variable name from `REDIS_URL` to `ATMOS_REDIS_URL` in error message

why

• Error message was referencing incorrect environment variable name
• Ensures error message matches the actual environment variable being checked in the code
• Helps developers quickly identify and fix configuration issues

Summary by CodeRabbit

• Bug Fixes
  • Revised the error message to clearly specify which environment variable is required for the Redis connection configuration, ensuring better clarity for users during setup.

allow user to specify default value when using store @mcalhoun (#1020)

## what

• Added support for default values in the !store YAML function using the pipe (|) syntax
• Added comprehensive test coverage for the store function, including default value scenarios
• Updated documentation to reflect the new default value functionality

why

• Provides a fallback mechanism when store values are not found, preventing errors
• Improves user experience by allowing graceful handling of missing values
• Makes the store function more resilient and flexible in different environments
• Support cold-start scenarios where components the target component depends on haven't been provisioned yet

references

• Related to store functionality described in /core-concepts/projects/configuration/stores
• Implements similar default value patterns found in other YAML processors

Summary by CodeRabbit

• New Features
  • Introduced an optional default value for YAML store lookups, allowing a fallback when a key is not found.
  • Enhanced parameter parsing and error handling for a smoother user experience.
• Tests
  • Added comprehensive tests to cover diverse lookup scenarios and default value usage.
• Documentation
  • Updated the YAML store function guide to include details on the new default value parameter and its usage.

move hook and store test @mcalhoun (#1021)

## what - Relocated test fixtures from `testdata/fixtures/hooks-test` to `tests/fixtures/scenarios/hooks-test` - Renamed test components from `random1/random2` to `component1/component2` for better clarity - Updated component path from `random` to `hook-and-store` to better reflect its functionality - Fixed typo in test comment ("deeploy" to "deploy")

why

• Improves test organization by moving fixtures to a more standardized location
• Makes test components and their purposes more self-documenting through better naming
• Aligns component names with their actual functionality (hook and store operations)
• Enhances code readability and maintainability

references

• No external references or issues to link

Sanitize snapshots @osterman (#1002)

## what - Replace the repo root with a place holder path

why

• Snapshots were leaking developer environment details, breaking golden snapshots, and complicating diffs
• Most diffs were relates to file path differences between Linux/MacOS/Windows
• repo root differs between workstations, depending on who generates the snapshots

references

• #939

Summary by CodeRabbit

• New Features

  • CLI command outputs now present generic, standardized file paths instead of user-specific ones, improving clarity and consistency.

• Bug Fixes

  • Enhanced output sanitization and error handling ensure that displayed paths remain uniform across environments.

• Tests

  • Updated expected outputs for configuration tests to streamline validation criteria and focus on key fields.

These improvements contribute to a cleaner and more consistent configuration display, leading to a better overall user experience.

restore hooks functionality @mcalhoun (#1010)

## what

• Restore the hooks functionality to atmos, since it was accidentally removed in a previous PR
• Implemented a new hooks system for Terraform commands
• Added support for after.terraform.apply events
• Created a Redis-based store command for persisting Terraform outputs
• Added integration tests for hooks and store functionality

why

• Enables automation of post-deployment tasks through hooks
• Provides a mechanism to share Terraform outputs between different components
• Allows for more flexible and maintainable infrastructure deployment workflows
• Ensures reliable state management across component deployments

references

• Related to terraform hooks and event handling
• Implements Redis-based state storage for cross-component communication

Summary by CodeRabbit

• New Features

  • Enhanced the Terraform commands to support pre- and post-execution hooks that enable custom actions during deployments.
  • Improved the mechanism for managing and storing outputs, facilitating cross-component integrations.
  • Introduced new hooks and configuration structures to streamline output management between components.
  • Added a new YAML configuration file with detailed project settings, including Redis store and Terraform configurations.
  • Introduced a new StoreCommand structure for handling outputs within hooks.

• Bug Fixes

  • Removed deprecated functions and streamlined command execution flow for improved reliability.

• Documentation

  • Expanded configuration examples and messaging for better handling of deployment settings, including environment variable management.

update artifactory store to allow anonymous access @mcalhoun (#1011)

## what - Added support for anonymous access to Artifactory repositories - Added conditional logic to only set access token if it's not "anonymous" - Updated documentation to explain anonymous access functionality

why

• Enables users to access public Artifactory repositories without authentication
• Provides flexibility for repositories that allow anonymous access
• Simplifies configuration for public repository access

references

• Related to Artifactory anonymous access documentation: https://jfrog.com/help/r/jfrog-platform-administration-documentation/permissions

Summary by CodeRabbit

• New Features
  • Enhanced authentication for Artifactory: The system now supports anonymous access, enabling more flexible repository connections.
• Documentation
  • Updated configuration guidance to include the new anonymous access option in the project documentation, with emphasis on security considerations for token management.

update artifactory store to use getKey @mcalhoun (#1017)

## what - Refactored the `getKey` method in `ArtifactoryStore` to use a shared key generation function - Simplified key path construction by separating prefix handling from the main path generation

why

• Reduces code duplication by leveraging a common key generation function
• Improves maintainability by separating concerns between prefix handling and path construction
• Makes the code more consistent with other store implementations

references

• Related to key generation standardization across storage implementations

Summary by CodeRabbit

• Refactor
  • Streamlined internal key creation logic to enhance maintainability and clarity.
  • Ensured that public functionalities remain consistent with no visible changes to the end-user.

feat: add spinner during `atmos validate stacks` operations @RoseSecurity (#1005)

## why

• It can be difficult to tell whether the command is hanging or actively running in the background. Here’s the current output:

 √ . [infra] (HOST) workspace ⨠ atmos validate stacks

Then:

 √ . [infra] (HOST) workspace ⨠ atmos validate stacks
all stacks validated successfully

what

• Add a spinner to the atmos validate stacks command
• Closes #1003

references

• Terraform Output Reference

Summary by CodeRabbit

• New Features
  • Introduced a spinner indicator that provides live visual feedback during the Atmos Stacks validation process. This enhancement gracefully adapts to both interactive and non-interactive terminal sessions, offering a fallback message when needed, and stops promptly if errors occur.
  • Added output messages indicating the start and successful completion of the Atmos Stacks validation.

update aws param ...