v1.135.0

Implement Custom Markdown Styling for Workflow Commands @Cerebrovinny (#853)

Implement Custom Markdown Styling for Workflow Commands

What

• Added custom markdown styling support for workflow command outputs
• Implemented a configurable markdown styling system through atmos.yaml
• Added fallback to built-in default styles when no custom styles are defined
• Added new workflow error templates in markdown format
• Improved code readability and maintainability in markdown rendering logic

Why

• Enhances user experience
• Allows users to define their own color schemes and styling preferences
• Improves error message readability with consistent formatting and styling
• Makes the CLI more accessible by supporting both default and custom color schemes
• Follows modern CLI design patterns with rich text formatting

Technical Details

• Added markdown settings section in atmos.yaml for custom styling configuration
• Implemented style inheritance system (custom styles override built-in defaults)
• Added support for styling:
  • Document text and background colors
  • Headings (H1-H6) with custom colors and formatting
  • Code blocks with syntax highlighting
  • Links with custom colors and underlining
  • Blockquotes and emphasis styles
• Enhanced error handling with structured markdown templates
• Added proper fallback mechanisms for style configuration

References

• Implements styling using glamour for terminal markdown rendering
• Follows ANSI terminal styling standards
• https://github.com/charmbracelet/bubbletea
• https://github.com/charmbracelet
• https://github.com/charmbracelet/glow
• https://github.com/charmbracelet/glamour/blob/master/styles/gallery/README.md

Testing

The implementation has been tested with:

• Custom styling configurations in atmos.yaml

• Default styling fallback when no custom styles are defined

v1.134.0

🚀 Enhancements

Support default values for arguments in Atmos custom commands @Listener430 (#905)

what

• Support default values for arguments in Atmos custom commands in atmos.yaml

why

• Allow specifying default values and don't not require the users to provide the values when invoking the custom commands

before

a custom cli-command is defined

after

v1.133.0

Replace `path` with `filepath` @haitham911 @aknysh (#900)

what

Replace path with filepath

why

• Different operating systems use different path separators (/ on Unix-based systems like Linux and macOS, and \ on Windows).
  filepath package automatically handles these differences, making code platform-independent. It abstracts the underlying file system separator, so we don't have to worry about whether you're running on Windows or Unix-based systems

v1.132.0

Add support for `atmos terraform providers` commands @Listener430 @aknysh (#866)

what

• Add support for atmos terraform providers commands
• Fix panic executing atmos terraform providers lock <component> --stack <stack> command when a non existing component or stack were specified
• Update atmos validate component <component> --stack <stack> command

why

• Support the following commands:
  • atmos terraform providers lock <component> --stack<stack>
  • atmos terraform providers schema <component> --stack<stack> -- -json
  • atmos terraform providers mirror <component> --stack<stack> -- <directory>

atmos terraform providers lock vpc-flow-logs-bucket -s plat-ue2-staging

atmos terraform providers mirror vpc-flow-logs-bucket -s plat-ue2-staging -- ./tmp

• Do not show help when executing atmos validate component <component> --stack <stack> command

atmos validate component vpc-flow-logs-bucket -s plat-ue2-stagin

references

• https://developer.hashicorp.com/terraform/cli/commands/providers
• https://developer.hashicorp.com/terraform/cli/commands/providers/lock
• https://developer.hashicorp.com/terraform/cli/commands/providers/mirror
• https://developer.hashicorp.com/terraform/cli/commands/providers/schema

v1.131.0

Revert "Replace path.Join with filepath.Join (#856)" @osterman (#887)

This reverts commit 2051592.

what

• Manual revert of #856

why

• It broke too many things that were are to debug, and we lacked tests to catch the situation.
• We've added windows tests in, and should revisit this.
  • #877
  • #875

Trigger workflows from GitHub actions bot @osterman (#890)

what

• Call workflow dispatch to build previews and run tests

why

• Automated PRs from github-actions[bot] will not trigger workflows (by design) unless a PAT is used
• This approach doesn't require introcing a PAT and leverages mergify instead

Fix Mocks for Windows @osterman (#877)

what

• Run commands depending on the flavor of OS
• Add e2e smoke tests to verify commands work

why

• Windows behaves differently from Linux/macOS
• #875 introduced windows testing
• Catch certain cases when we have no unit tests for CLI behaviors (tests for condition @mcalhoun encountered with an infinite loop in atmos version)

Add Windows & macOS Acceptance Tests @osterman (#875)

what

• We broke atmos in #856 attempting to improve windows support, but instead we broke it

why

• We don't currently run any tests on windows and macOS
• Slight differences between OSes can cause big problems and are hard to catch
• Most of our developer team is on macOS, but more and more Windows users are using atmos
• To maintain stability, it's critical we test all mainstream platforms

references

• Relates to #856 (broke atmos on windows)

v1.130.0

TUI package manager for `atmos vendor pull` @haitham911 (#768)

what

• TUI package manager for atmos vendor pull
• Show the download progress for each vendored package
• Display the versions of the vendored packages
• Add --everything flag for non TTY mode

why

• Improve user experience

v1.129.0

Improve `!terraform.output` Atmos YAML function. Implement `static` remote state backend for `!terraform.output` and `atmos.Component` functions @aknysh (#863)

what

• Improve !terraform.output Atmos YAML function

• Implement static remote state backend for !terraform.output and atmos.Component functions

• Add more advanced usage examples of the !template Atmos YAML function

• Fix the error messages when the user specifies an invalid component names in atmos terraform plan/apply

• Update docs

  • https://atmos.tools/core-concepts/stacks/yaml-functions/terraform.output/

  • https://atmos.tools/core-concepts/stacks/yaml-functions/template/

  • https://atmos.tools/core-concepts/stacks/templates/functions/atmos.Component/

why

Improve !terraform.output Atmos YAML function

The !template Atmos YAML function now can be called with either two or three parameters:

  # Get the `output` of the `component` in the current stack
  !terraform.output <component> <output>

  # Get the `output` of the `component` in the provided stack
  !terraform.output <component> <stack> <output>

Examples:

components:
  terraform:
    my_lambda_component:
      vars:
        vpc_config:
          # Output of type string
          security_group_id: !terraform.output security-group/lambda id
          security_group_id2: !terraform.output security-group/lambda2 {{ .stack }} id
          security_group_id3: !terraform.output security-group/lambda3 {{ .atmos_stack }} id
          # Output of type list
          subnet_ids: !terraform.output vpc private_subnet_ids
          # Output of type map
          config_map: !terraform.output config {{ .stack }} config_map

NOTE: Using the .stack or .atmos_stack template identifiers to specify the stack is the same as calling the !template function with two parameters without specifying the current stack, but without using Go templates.
If you need to get an output of a component in the current stack, using the !template function with two parameters
is preferred because it has a simpler syntax and executes faster.

Implement static remote state backend for !terraform.output and atmos.Component functions

Atmos supports brownfield configuration by using the remote state of type static.

For example:

When the functions are executed, Atmos detects that the test component has the static remote state configured,
and instead of executing terrafrom output, it just returns the static values from the remote_state_backend.static section.

Executing the command atmos describe component test2 -s <stack> produces the following result:

Add more advanced usage examples of the !template Atmos YAML function

The !template Atmos YAML function can be used to make your stack configuration DRY and reusable.

For example, suppose we need to restrict the Security Group ingresses on all components provisioned in the infrastructure
(e.g. EKS cluster, RDS Aurora cluster, MemoryDB cluster, Istio Ingress Gateway) to a specific list of IP CIDR blocks.

We can define the list of allowed CIDR blocks in the global settings section (used by all components in all stacks)
in the allowed_ingress_cidrs variable:

settings:
  allowed_ingress_cidrs:
    - "10.20.0.0/20"  # VPN 1
    - "10.30.0.0/20"  # VPN 2

We can then use the !template function with the following template in all components that need their Security Group
to be restricted:

# EKS cluster
# Allow ingress only from the allowed CIDR blocks
allowed_cidr_blocks: !template '{{ toJson .settings.allowed_ingress_cidrs }}'

# RDS cluster
# Allow ingress only from the allowed CIDR blocks
cidr_blocks: !template '{{ toJson .settings.allowed_ingress_cidrs }}'

# Istio Ingress Gateway
# Allow ingress only from the allowed CIDR blocks
security_group_ingress_cidrs: !template '{{ toJson .settings.allowed_ingress_cidrs }}'

The !template function and the '{{ toJson .settings.allowed_ingress_cidrs }}' expression allows you to
use the global allowed_ingress_cidrs variable and the same template even if the components have different
variable names for the allowed CIDR blocks (which would be difficult to implement using
Atmos inheritance or other Atmos design patterns).

NOTE:
To append additional CIDRs to the template itself, use the list and Sprig concat functions:

allowed_cidr_blocks: !template '{{ toJson (concat .settings.allowed_ingress_cidrs (list "172.20.0.0/16")) }}'

v1.128.0

Replace `path.Join` with `filepath.Join` @samtholiya (#856)

what

• Replaced all instances of path.Join with filepath.Join in the codebase
• Updated imports to use the path/filepath package instead of path

why

• Cross-platform compatibility: path.Join does not respect platform-specific path separators, causing potential issues on non-Unix systems (e.g. Windows)
• Correct usage: filepath.Join is designed for working with filesystem paths, ensuring semantic correctness
• Ensures the codebase adheres to Go best practices for handling file paths.

References

• Go Documentation on filepath.Join

Mergify @osterman (#862)

what

• Add mergify
• Add tests

why

• Mergify rules have some nice things like letting us know when PRs are stale or conflicted

v1.127.0

Implement Atmos version check configuration and functionality @Listener430 (#844)

what

• Implement Atmos version check configuration and functionality
• Add the --check flag to the atmos version command to force it to check for the latest Atmos release (regardless of the enabled flag and the cache config) and print the upgrade message
• Add the version config section version in atmos.yaml
• Update docs

why

• Remove unnecessary upgrade message for some Atmos commands
• Introduce config mechanism to turn on/off the update notifications and their frequency
• The --check flag for the atmos version command forces it to check for the latest Atmos release (regardless of the enabled flag and the cache config) and print the upgrade message

atmos version --check

before for non --help command, the Atmos upgrade box was displayed:

now:

Added the version config section in atmos.yaml:

version:
  check:
    enabled: true
    timeout: 1000 # ms
    frequency: 1h

.atmos/cache.yaml file is generated with time stamp:

and the upgrade box is not displayed until the time interval exceed the specified in the config

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