v1.92.0

Improve error handling @haitham911 (#726)

what

• Improve error handling , check log level Trace for detailed trace information

why

• Print detailed error only when log level Trace

Document vendoring from private git repos @osterman (#723)

what

• Document how to vendor from private GitHub repos
• Document template syntax for vendoring

why

• The syntax is a bit elusive, and it's a common requirement

v1.91.0

feat: support for `.yml` and `.yaml` file extensions for component vendoring @RoseSecurity (#725)

## what

• Support for .yml and .yaml when vendoring using component.yaml

why

• The tool is strict about needing component.yaml, file ending for yaml files is a matter of preference and both should be accepted.

testing

• make build

# component.yml
❯ ./build/atmos vendor pull -c aurora-postgres-resources
Pulling sources for the component 'aurora-postgres-resources' from 'github.com/cloudposse/terraform-aws-components.git//modules/aurora-postgres-resources?ref=1.511.0' into 
'/Users/infra/components/terraform/aurora-postgres-resources'

# component.yaml
❯ ./build/atmos vendor pull -c aurora-postgres-resources
Pulling sources for the component 'aurora-postgres-resources' from 'github.com/cloudposse/terraform-aws-components.git//modules/aurora-postgres-resources?ref=1.511.0' into 
'/Users/infra/components/terraform/aurora-postgres-resources'

# Missing both
❯ ./build/atmos vendor pull -c aurora-postgres-resources
component vendoring config file does not exist in the '/Users/infra/components/terraform/aurora-postgres-resources' folder

references

• Closes the following issue

Summary by CodeRabbit

Summary by CodeRabbit

• New Features

  • Enhanced file existence checks for component configuration, now supporting both .yaml and .yml file formats.

• Refactor

  • Streamlined variable declarations for improved readability without changing logic.

Add the guide to install atmos using aqua @suzuki-shunsuke (#720)

## what

Add the guide to install atmos using aqua.

why

aqua is a CLI Version Manager written in Go.
aqua supports various tools including atmos, Terraform, Helm, Helmfile.

Confirmation

I have launched the webserver on my laptop according to the guide.

references

Summary by CodeRabbit

• New Features

  • Introduced a new installation method for Atmos using the aqua CLI version manager.
  • Added a dedicated tab in the installation guide for aqua, including instructions for setup and usage.

• Documentation

  • Updated the "Install Atmos" document to enhance user guidance on installation options.

v1.90.0

Always template vendor source and targets @mss (#712)

## what

This change improves the templating within vendor manifests slightly: It officially adds support for the Component field to both source and targets.

These features were already supported but mostly undocumented and hidden behind an implicit switch: The templating was only triggered if the Version field was set. Which was also the only officially supported field.

In reality though all fields from the current source definition were available but in the state they were currently in, depending on the order of the templates.

With this change

• It is clearly documented which fields are supported in which YAML values.
• Only the two static fields are supported.
• The values are always templated.

Theoretically this could be a breaking change if somebody used no version field but curly braces in their paths. Or relied on the half-populated source data structure to refer to unsupported fields. If xkcd 1172 applies it should be possible to amend this logic to add more officially supported fields.

why

I was looking for a way to restructure our vendoring like the examples in examples/demo-vendoring/vendor.yaml to avoid copy and paste errors when we release new component versions.

I actually only found out about that demo when I was done writing this code since the templating was never triggered without a version field and the documentation didn't mention it.

references

• https://github.com/cloudposse/atmos/blob/v1.88.1/examples/demo-vendoring/vendor.yaml
• https://atmos.tools/core-concepts/vendor/vendor-manifest/#vendoring-manifest

Summary by CodeRabbit

• New Features

  • Enhanced vendoring configuration with support for dynamic component referencing in vendor.yaml.
  • Improved handling of source and targets attributes for better organization and flexibility.

• Documentation

  • Updated documentation for vendoring configuration, including clearer instructions and examples for managing multiple vendor manifests.
  • Added explanations for included_paths and excluded_paths attributes to improve understanding.

Fix a reference to an undefined output in GitHub Actions @suzuki-shunsuke (#718)

## what

1. Fix a reference to an undefined output in GitHub Actions.

https://github.com/cloudposse/atmos/blob/6439a64488856c461a9eb7a8f7adb30901080cef/.github/workflows/test.yml#L312

The step config is not found.
This bug was added in #612 .

• b53d696
• #612

2. Use a version variable for easier updates.

env:
  TERRAFORM_VERSION: "1.9.7"

steps:
  - uses: hashicorp/setup-terraform@v3
    with:
      terraform_version: ${{ env.TERRAFORM_VERSION }}

#717 (comment)

3. Stop installing terraform wrapper

By default hashicorp/setup-terraform installs a wrapper of Terraform to output Terraform stdout and stderr as step's outputs.
But we don't need them, so we shouldn't install the wrapper.

https://github.com/hashicorp/setup-terraform

- uses: hashicorp/setup-terraform@v3
  with:
    terraform_wrapper: false

why

references

Summary by CodeRabbit

• Chores
  • Updated workflow configurations for improved maintainability.
  • Introduced a new environment variable TERRAFORM_VERSION for version management.

ci: install Terraform to fix CI failure that Terraform is not found @suzuki-shunsuke (#717)

## what

Install Terraform using hashicorp/setup-terraform action in CI.

why

CI failed because Terraform wasn't found.

https://github.com/cloudposse/atmos/actions/runs/11307359580/job/31449045566
https://github.com/cloudposse/atmos/actions/runs/11307359580/job/31449046010

Run cd examples/demo-context
all stacks validated successfully
exec: "terraform": executable file not found in $PATH

This is because ubuntu-latest was updated to ubuntu-24.04 and Terraform was removed from it.

https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md

On the other hand, Ubuntu 22.04 has Terraform.

https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md

references

Summary by CodeRabbit

• Chores
  • Enhanced workflow for testing and linting by integrating Terraform setup in multiple job sections.
  • Updated the lint job to dynamically retrieve the Terraform version for improved flexibility.

v1.89.0

Improve error stack trace. Add `--stack` flag to `atmos describe affected` command. Improve `atmos.Component` template function @aknysh (#714)

## what

• Improve error stack trace
• Add --stack flag to atmos describe affected command
• Improve atmos.Component template function

why

• On any error in the CLI, print Go stack trace only when Atmos log level is Trace - improve user experience

• The --stack flag in the atmos describe affected command allows filtering the results by the specific stack only:

atmos describe affected --stack plat-ue2-prod

Affected components and stacks:

[
  {
    "component": "vpc",
    "component_type": "terraform",
    "component_path": "examples/quick-start-advanced/components/terraform/vpc",
    "stack": "plat-ue2-prod",
    "stack_slug": "plat-ue2-prod-vpc",
    "affected": "stack.vars"
  }
]

• In the atmos.Component template function, don't execute terraform output on disabled and abstract components. The disabled components (when enabled: false) don't produce any terraform outputs. The abstract components are not meant to be provisioned (they are just blueprints for other components with default values), and they don't have any outputs.

Summary by CodeRabbit

Release Notes

• New Features

  • Added a --stack flag to the atmos describe affected command for filtering results by stack.
  • Enhanced error handling across various commands to include configuration context in error logs.

• Documentation

  • Updated documentation for the atmos describe affected command to reflect the new --stack flag.
  • Revised "Atlantis Integration" documentation to highlight support for Terraform Pull Request Automation.

• Dependency Updates

  • Upgraded several dependencies, including Atmos version from 1.88.0 to 1.89.0 and Terraform version from 1.9.5 to 1.9.7.

Correct outdated 'myapp' references in simple tutorial @jasonwashburn (#707)

## what

Corrects several (assuming) outdated references to a 'myapp' component rather than the correct 'station' component in the simple tutorial.

Also corrects the provided example repository hyperlink to refer to the correct weather example 'quick-start-simple' used in the tutorial rather than 'demo-stacks'

why

Appears that the 'myapp' references were likely just missed during a refactor of the simple tutorial. Fixing them alleviates confusion/friction for new users following the tutorial. Attempting to use the examples/references as-is results in various errors as there is no 'myapp' component defined.

references

Also closes #664

Summary by CodeRabbit

• New Features

  • Renamed the component from myapp to station in the configuration.
  • Updated provisioning commands in documentation to reflect the new component name.

• Documentation

  • Revised "Deploy Everything" document to replace myapp with station.
  • Enhanced "Simple Atmos Tutorial" with updated example link and clarified instructional content.

Fix incorrect terraform flag in simple tutorial workflow example @jasonwashburn (#709)

## what

Fixes inconsistencies in the simple-tutorial extra credit section on workflows that prevent successful execution when following along.

why

As written, the tutorial results in two errors, one due to an incorrect terraform flag, and one due to a mismatch between the defined workflow name, and the provided command in the tutorial to execute it.

references

Closes #708

Fix typos @NathanBaulch (#703)

Just thought I'd contribute some typo fixes that I stumbled on. Nothing controversial (hopefully).

Use the following command to get a quick summary of the specific corrections made:

git diff HEAD^! --word-diff-regex='\w+' -U0 \
  | grep -E '\[\-.*\-\]\{\+.*\+\}' \
  | sed -r 's/.*\[\-(.*)\-\]\{\+(.*)\+\}.*/\1 \2/' \
  | sort | uniq -c | sort -n

FWIW, the top typos are:

• usign
• accross
• overriden
• propogate
• verions
• combinatino
• compoenents
• conffig
• conventionss
• defind

Fix version command in simple tutorial @jasonwashburn (#705)

## what

• Corrects incorrect atmos --version command to atmos version in simple tutorial docs.

why

• Documentation is incorrect.

references

closes #704

docs: add installation guides for asdf and Mise @mtweeman (#699)

## what

Docs for installing Atmos via asdf or Mise

why

As of recent, Atmos can be installed by asdf and Mise. Installation guides are not yet included on the website. This PR aims to fill this gap.

references

Plugin repo

Use Latest Atmos GitHub Workflows Examples with `RemoteFile` Component @milldr (#695)

## what - Created the `RemoteFile` component - Replace all hard-coded files with `RemoteFile` call

why

• These workflows quickly get out of date. We already have these publicly available on cloudposse/docs, so we should fetch the latest pattern instead

references

• SweetOps slack thread

Update Documentation and Comments for Atmos Setup Action @RoseSecurity (#692)

## what

• Updates comment to reflect action defaults
• Fixes atmos-version input

why

• Fixes input variables to match acceptable action variables

references

• Setup Actions

v1.88.1

🚀 Enhancements

BUG: fix error with affected stack uploads @mcalhoun (#691)

## what

• Fix an error with affected stack uploads to atmos pro
• Fix an error with URL extraction for locally cloned repos
• Add better JSON formatting for affected stacks
• Add additional debugging info

v1.88.0

Update the `Go` YAML lib from `gopkg.in/yaml.v2` to `gopkg.in/yaml.v3`. Support YAML v1.2 (latest version) @aknysh (#690)

## what

• Update the Go YAML lib from gopkg.in/yaml.v2 to gopkg.in/yaml.v3
• Support YAML v1.2 (latest version)
• Support YAML explicit typing (explicit typing is denoted with a tag using the exclamation point (“!”) symbol)
• Improve code, e.g. add YAML wrappers in one yaml_utils file (which imports gopkg.in/yaml.v3) to control all YAML marshaling and un-marshaling from one place

why

gopkg.in/yaml.v3

The main differences between gopkg.in/yaml.v3 and gopkg.in/yaml.v2 include enhancements in functionality, bug fixes, and improvements in performance. Here's a summary of key distinctions:

1. Better Conformance to YAML 1.2 Specification:

• gopkg.in/yaml.v3 offers improved support for the YAML 1.2 specification. This includes better handling of complex YAML features such as core schema, block styles, and anchors.
• gopkg.in/yaml.v2 is more aligned with YAML 1.1, meaning it might not fully support some of the YAML 1.2 features.

2. Node API Changes:

• gopkg.in/yaml.v3 introduced a new Node API, which provides more control and flexibility over parsing and encoding YAML documents. This API is more comprehensive and allows for detailed inspection and manipulation of YAML content.
• gopkg.in/yaml.v2 has a simpler node structure and API, which might be easier to use for simple use cases but less powerful for advanced needs.

3. Error Handling:

• gopkg.in/yaml.v3 offers improved error messages and better context for where an error occurs during parsing. This makes it easier to debug and correct YAML syntax errors.
• gopkg.in/yaml.v2 has less detailed error reporting, which can make debugging more challenging.

4. Support for Line and Column Numbers:

• gopkg.in/yaml.v3 includes support for tracking line and column numbers of nodes, which can be useful when dealing with large or complex YAML files.
• gopkg.in/yaml.v2 does not provide this level of detail in terms of tracking where nodes are located within the YAML document.

5. Performance:

• gopkg.in/yaml.v3 has various performance improvements, particularly in the encoding and decoding process. However, these improvements might not be significant in all scenarios.
• gopkg.in/yaml.v2 might be slightly faster in certain cases, particularly when dealing with very simple YAML documents, due to its simpler feature set.

6. Deprecation of Legacy Functions:

• gopkg.in/yaml.v3 deprecates some older functions that were available in v2, encouraging developers to use more modern and efficient alternatives.
• gopkg.in/yaml.v2 retains these older functions, which may be preferred for backward compatibility in some projects.

7. Anchors and Aliases:

• gopkg.in/yaml.v3 has better handling of YAML anchors and aliases, making it more robust in scenarios where these features are heavily used.
• gopkg.in/yaml.v2 supports anchors and aliases but with less robustness and flexibility.

8. API Changes and Compatibility:

• gopkg.in/yaml.v3 introduces some API changes that are not backward-compatible with v2. This means that upgrading from v2 to v3 might require some code changes.
• gopkg.in/yaml.v2 has been widely used and is stable, so it may be preferable for projects where stability and long-term support are critical.

YAML v1.2

YAML v1.1 and YAML v1.2 differ in several key aspects, particularly in terms of specification, syntax, and data type handling. Here's a breakdown of the most significant differences:

1. Specification and Goals:

• YAML 1.1 was designed with some flexibility in its interpretation of certain constructs, aiming to be a human-readable data serialization format that could also be easily understood by machines.
• YAML 1.2 was aligned more closely with the JSON specification, aiming for better interoperability with JSON and standardization. YAML 1.2 is effectively a superset of JSON.

2. Boolean Values:

• YAML 1.1 has a wide range of boolean literals, including y, n, yes, no, on, off, true, and false. This flexibility could sometimes lead to unexpected interpretations.
• YAML 1.2 standardizes boolean values to true and false, aligning with JSON. This reduces ambiguity and ensures consistency.

3. Integers with Leading Zeros:

• YAML 1.1 interprets integers with leading zeros as octal (base-8) numbers. For example, 012 would be interpreted as 10 in decimal.
• YAML 1.2 no longer interprets numbers with leading zeros as octal. Instead, they are treated as standard decimal numbers, which aligns with JSON. This change helps avoid confusion.

4. Null Values:

• YAML 1.1 allows a variety of null values, including null, ~, and empty values (e.g., an empty string).
• YAML 1.2 standardizes the null value to null (or an empty value), aligning with JSON's null representation.

5. Tag Handling:

• YAML 1.1 uses an unquoted !! syntax for tags (e.g., !!str for a string). The tag system is more complex and includes non-standard tags that can be confusing.
• YAML 1.2 simplifies tag handling and uses a more JSON-compatible syntax, with less emphasis on non-standard tags. Tags are optional and less intrusive in most use cases.

6. Floating-Point Numbers:

• YAML 1.1 supports special floating-point values like .inf, -.inf, and .nan with a dot notation.
• YAML 1.2 aligns with JSON and supports Infinity, -Infinity, and NaN, which are the standard representations in JSON.

7. Direct JSON Compatibility:

• YAML 1.2 is designed to be a strict superset of JSON, meaning any valid JSON document is also a valid YAML 1.2 document. This was not the case in YAML 1.1, where certain JSON documents could be interpreted differently.

8. Indentation and Line Breaks:

• YAML 1.2 introduced more consistent handling of line breaks and indentation. While YAML 1.1 was flexible, it sometimes led to ambiguities in how line breaks and whitespace were interpreted.
• YAML 1.2 has clearer rules, reducing the potential for misinterpretation of line breaks and indentation.

9. Miscellaneous Syntax Changes:

• YAML 1.2 introduced some syntax changes for better clarity and alignment with JSON. For instance, YAML 1.2 removed support for single-quoted multiline strings, which were present in YAML 1.1.

10. Core Schema vs. JSON Schema:

• YAML 1.2 introduced the concept of schemas, particularly the Core schema, which aims to be YAML's native schema, and the JSON schema, which strictly follows JSON's data types and structures.
• YAML 1.1 did not have this formal schema distinction, leading to more flexible but sometimes less predictable data handling.

Summary:

• YAML 1.2 is more standardized, consistent, and aligned with JSON, making it more predictable and easier to interoperate with JSON-based systems.
• YAML 1.1 offers more flexibility and a wider range of literal values, but this flexibility can sometimes lead to ambiguities and unexpected behavior.

references

• https://yaml.org/spec/1.2.2
• https://yaml.org/spec/1.1
• https://pkg.go.dev/gopkg.in/yaml.v2
• https://pkg.go.dev/gopkg.in/yaml.v3

v1.87.1

Support `atmos terraform apply --from-plan` with additional flags @duncanaf (#684)

what

• Change argument generation for atmos terraform apply to make sure the plan-file arg is placed after any flags specified by the user

why

• Terraform is very picky about the order of flags and args, and requires all args (e.g. plan-file) to come after any flags (e.g. --parallelism=1), or it crashes.
• atmos terraform apply accepts a plan-file arg, or generates one when --from-plan is used. When this happens, it currently puts the plan-file arg first, before any additional flags specified by the user.
• This breaks when additional flags are specified, e.g. atmos terraform apply --from-plan -- -parallelism=1. In this example, atmos tries to call terraform apply <planfile> --paralellism=1 and terraform crashes with Error: Too many command line arguments

v1.87.0

Update/improve Atmos UX @aknysh (#679)

what & why

• Improve error messages in the cases when atmos.yaml CLI config file is not found, and if's it found, but points to an Atmos stacks directory that does not exist

• When executing atmos command to show the terminal UI, do not evaluate the Go templates in Atmos stack manifests to make the command faster since the TUI just shows the names of the components and stacks and does not need the components' configurations

• Fix/restore the TUI borders for the commands atmos and atmos workflow around the selected columns. The BorderStyle functionality was changed in the latest releases of the charmbracelet/lipgloss library, preventing the borders around the selected column from showing

atmos

atmos workflow

Announce Cloud Posse's Refarch Docs @osterman (#680)

what

• Announce cloud posse refarch docs

Add atmos pro stack locking @mcalhoun (#678)

what

• add the atmos pro lock and atmos pro unlock commands

v1.86.2

Improve logging for the template function `atmos.Component`. Generate backend config and provider override files in `atmos.Component` function @aknysh (#674)

what

• Improve logging for the template function atmos.Component
• Generate backend config and provider override files in atmos.Component function
• Update docs

why

• Add more debugging information and fix issues with the initial implementation of the atmos.Component function when the backend config file backend.tf.json (if enabled in atmos.yaml) and provider overrides file providers_override.tf.json (if configured in the providers section) were not generated, which prevented the function atmos.Component from returning the outputs of the component when executing in GitHub actions

• When the environment variable ATMOS_LOGS_LEVEL is set to Trace, the template function atmos.Component will log the execution flow and the results of template evaluation - useful for debugging

   ATMOS_LOGS_LEVEL=Trace atmos describe component <component> -s <stack>
   ATMOS_LOGS_LEVEL=Trace atmos terraform plan <component> -s <stack>
   ATMOS_LOGS_LEVEL=Trace atmos terraform apply <component> -s <stack>

bump http context timeout for upload to atmos pro @mcalhoun (#656)

what

Increase the maximum http timeout when uploading to atmos pro

why

There are cases when there are a large number of stacks and a large number of workflows that this call can exceed 10 seconds

v1.86.1

Improve logging for the template function `atmos.Component` @aknysh (#672)

## what

• Improve logging for the template function atmos.Component
• Update Golang to the latest version 1.23

why

• When the environment variable ATMOS_LOGS_LEVEL is set to Trace, the template functions atmos.Component and atmos.GomplateDatasource will log the execution flow and the results of template evaluation - useful for debugging

   ATMOS_LOGS_LEVEL=Trace atmos terraform plan <component> -s <stack>

This PR adds more debugging information and shows the results of the atmos.Component execution, and shows if the result was found in the cache:

Found component 'template-functions-test' in the stack 'tenant1-ue2-prod' in the stack manifest 'orgs/cp/tenant1/prod/us-east-2'
ProcessTmplWithDatasources(): template 'all-atmos-sections' - evaluation 1

Converting the variable 'test_list' with the value
[
      "list_item_1",
      "list_item_2",
      "list_item_3"
    ]
from JSON to 'Go' data type

Converted the variable 'test_list' with the value
[
      "list_item_1",
      "list_item_2",
      "list_item_3"
    ]
from JSON to 'Go' data type
Result: [list_item_1 list_item_2 list_item_3]

Converting the variable 'test_map' with the value
{
      "a": 1,
      "b": 2,
      "c": 3
    }
from JSON to 'Go' data type

Converted the variable 'test_map' with the value
{
      "a": 1,
      "b": 2,
      "c": 3
    }
from JSON to 'Go' data type
Result: map[a:1 b:2 c:3]

Converting the variable 'test_label_id' with the value
"cp-ue2-prod-test"
from JSON to 'Go' data type

Converted the variable 'test_label_id' with the value
"cp-ue2-prod-test"
from JSON to 'Go' data type
Result: cp-ue2-prod-test

Executed template function 'atmos.Component(template-functions-test, tenant1-ue2-prod)'

'outputs' section:
test_label_id: cp-ue2-prod-test
test_list:
- list_item_1
- list_item_2
- list_item_3
test_map:
  a: 1
  b: 2
  c: 3

Executing template function 'atmos.Component(template-functions-test, tenant1-ue2-prod)'
Found the result of the template function 'atmos.Component(template-functions-test, tenant1-ue2-prod)' in the cache
'outputs' section:
test_label_id: cp-ue2-prod-test
test_list:
- list_item_1
- list_item_2
- list_item_3
test_map:
  a: 1
  b: 2
  c: 3

add install instructions for atmos on windows/scoop @dennisroche (#649)

## what

add option/documentation for installing atmos using scoop.sh on windows.

scoop install atmos

scoop manifests will check GitHub releases and automatically update. no additional maintenance required for anyone 🥳.

why

needed an easy way for my team to install atmos

references

Fix docker build `ATMOS_VERSION` support `v*` tags @goruha (#671)

## what * Remove `v` for `ATMOS_VERSION` on docker build

why

• Cloudposse changed the tag template policy - now the tag is always prefixed with v.
  The tag passed as ATMOS_VERSION docker build argument

references

• https://github.com/cloudposse/atmos/actions/runs/10391667666/job/28775133282#step:3:4480