cloudposse/atmos v1.90.0

on GitHub

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.

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

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

• b53d696
• #612

1. 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)

1. 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.

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.