v1.163.0

Add examples and tests for `!include` Atmos YAML function @aknysh (#1080)

what

• Add examples and tests for !include Atmos YAML function
• Update atmos terraform commands that require processing of Go templates and Atmos YAML functions

why

• Test Atmos YAML function !include and show usage examples

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

init
plan
apply
deploy
destroy
generate
output
clean
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

Add more lint rules @osterman (#1082)

What

This PR adds and updates several golangci-lint rules to enforce stricter code quality and maintainability standards. Specifically, it:

• Enhances structured logging validation by configuring loggercheck to support charmbracelet/log, ensuring key-value pairs are formatted correctly.
• Forbids goto statements by enabling the banned-characters rule.
• Disallows multi-line errors (\n in error messages) using error-strings to improve error readability.
• Limits function length (function-length) to prevent overly large and unreadable functions.
• Restricts file size using file-length-limit to encourage modularity.
• Enforces cognitive complexity limits (cognitive-complexity) to prevent functions from becoming too complex.
• Checks cyclomatic complexity (cyclomatic) to encourage simpler, more maintainable logic.
• Prevents deeply nested if statements (nestif) to improve readability.
• Standardizes import ordering with gci.
• Ensures consistent comment formatting (godot).

Why

• Improved maintainability: Enforcing function size, file size, and complexity limits helps keep code more modular and readable.
• Better logging practices: By adding loggercheck rules for charmbracelet/log, we ensure structured logging best practices are followed.
• Stronger error handling: Disallowing multi-line errors improves error message parsing and readability.
• More readable control structures: By limiting goto and nested if statements, we prevent overly complex code paths.
• Standardized formatting: Enforcing import ordering and comment formatting ensures consistency across the codebase.
• Early detection of potential issues: These additional lint rules help catch problematic patterns before they become technical debt.

Rename GolangCI GHA Job, add lint target to `Makefile` @osterman (#1081)

what

• Add a lint target to the Makefile
• Pass GITHUB_SECRET explicitly
• Only comment on code additions
• Format job name with [lint] prefix
• Updated Dockerfile job name too match
• Set limits for the maximum statements per function and maximum functions per file

why

• Job name didn't match other linting jobs
• Make target is easier to run locally
• Our files are too large, which leads to more and more merge conflicts
• Our functions are too large, which increases the cognitive load required to understand what's going on

Add GolangCI Lint Configuration for Better Code Quality @osterman (#1078)

what

This PR improves our golangci-lint configuration to enforce better coding standards, catch common mistakes, and ensure consistency in our Go codebase.

• Function Length Enforcement (funlen)

  • Limits functions to 50 lines to improve readability and maintainability.

• Forbidden Function Calls (forbidigo)

  • Allows blocking specific function calls (e.g., deprecated logging functions).

• Enabling Additional Linters

  • gocritic: Adds several static analysis checks for code quality.
  • errcheck: Ensures all errors are properly handled.
  • gofumpt: Standardizes formatting beyond gofmt.
  • govet: Detects suspicious constructs.
  • staticcheck: Flags performance and correctness issues.
  • revive: A configurable linter for Go.
  • misspell: Detects common spelling mistakes.

• Custom gocritic Checks

  • Enables key rules such as:
    • rangeValCopy: Detects unnecessary copies in range loops.
    • hugeParam: Warns on large parameters that should be passed by reference.
    • commentedOutCode: Finds commented-out code blocks.
    • nestingReduce: Suggests ways to reduce nesting complexity.
    • preferFilepathJoin: Enforces using filepath.Join() instead of manual concatenation.

• Excludes Test Files from Function Length Check (funlen)

  • Test files (_test.go) are ignored for function length enforcement.

• Output Formatting Improved

  • Uses colored-line-number format for better readability in logs.

why

• Prevents oversized functions, making code easier to read and refactor.
• Ensures error handling is not skipped, improving reliability.
• Standardizes code formatting across the team.
• Detects common pitfalls like unnecessary copies, deep nesting, and improper path handling.

Fix exit codes for Atmos command @samtholiya (#1065)

what

• Fix exit codes for Atmos command

why

• Improved User Experience: It provides more accurate feedback to the user, reflecting the success or failure of the desired program.

• Better Integration with Other Tools: Many CI/CD systems, monitoring tools, or scripts rely on exit codes to determine whether a task has succeeded or failed. Matching the exit codes allows seamless integration with existing workflows.

• Debugging and Troubleshooting: By matching exit codes, users and developers can more easily trace issues and understand which program (or specific execution) caused the failure.

• This change helps ensure the CLI behaves more predictably and conforms to standard practices for handling exit codes.

Add shared configuration for RunsOn GHA runners @Nuru (#1075)

what

• Add shared configuration for RunsOn GHA runners

why

• Allow use of simple runner configuration labels like "large"

references

• https://runs-on.com/configuration/repo-config/

Document Atmos Development Conventions @osterman (#793)

what

• Explain when to display help vs usage, and their respective behaviors
• Explain when to use various log levels

why

• Improve code consistency as the dev team expands

Expose env variables `ATMOS_CLI_CONFIG_PATH` and `ATMOS_BASE_PATH` before running terraform and helm commands @haitham911 (#1072)

What

• Expose env variables ATMOS_CLI_CONFIG_PATH and ATMOS_BASE_PATH before running terraform and helm commands

Why

• The ENV variables ATMOS_CLI_CONFIG_PATH and ATMOS_BASE_PATH can be used in the Terraform and Helmfile components

Update Smoke Tests to Check for Stale Atmos Binary @osterman (#1063)

what

• Error if the atmos binary is older than the .go files
• Error if the atmos binary discovered from the PATH is not within the repository
• Introduce charmbracelet logger

why

• Smoketests run the atmos binary from the build
• We didn't check that the binary was stale, so an out of date binary could be used
• We didn't check that atmos from the build was in the PATH
• Logging wasn't easy because the test model isn't accessible everywhere, so using the charmbracelet logger is easy
• Developers frequently missed pertient log messages; color logs make it easier to see what's going on

screenshots

General info

Wrong atmos binary

Stale atmos binary

Fixed an issue with `vendor.yaml` source failing to accept `git::ssh` URI @elsayedmt (#1054)

what

• Modified the validation code to accept URL style SSH addresses accepted by go-getter

why

• Allow to checkout a bitbucket repo using an SSH key

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