cloudposse/atmos v1.206.0-rc.4

on GitHub

• Deleted Component Detection: atmos describe affected now detects components and stacks that have been deleted in HEAD (current branch) compared to BASE (target branch)
• New Output Fields: Added deleted (boolean) and deletion_type (string: component or stack) fields to the affected output schema
• New Affected Reasons: Added deleted and deleted.stack as valid affected reasons
• Integration Test Fixture: Added comprehensive test fixture at tests/fixtures/scenarios/atmos-describe-affected-deleted-detection/
• Bug Fix: Fixed issue where stacks that only exist in BASE (not HEAD) were not being discovered during comparison - the code now re-scans BASE directory for stack config files instead of just converting HEAD paths
• Documentation: Updated describe-affected.mdx with new fields, reasons, and CI/CD workflow examples
• GitHub Actions Guide: Added new section in affected-stacks.mdx for destroy workflow integration
• Blog Post: Added changelog entry announcing the feature
• Roadmap: Updated CI/CD initiative with shipped milestone (progress: 80%)

why

• Resource Leaks: Previously, when components or stacks were removed from configuration, CI/CD pipelines had no automated way to detect these deletions and trigger terraform destroy
• Manual Destruction Required: Users had to manually identify and destroy removed components, which was error-prone and could lead to orphaned cloud resources
• Incomplete CI/CD: Pipelines couldn't fully automate the infrastructure lifecycle - they could only handle creation and modification, not deletion
• Audit Gaps: No automated tracking of what infrastructure was removed from configuration

How It Works

The algorithm now performs a second pass over BASE stacks to detect deletions:

1. For each stack in BASE:

   • If stack doesn't exist in HEAD → all components marked as deleted.stack
   • If stack exists in HEAD → check each component
     • If component doesn't exist in HEAD → marked as deleted

2. Abstract components (metadata.type: abstract) are not reported as deleted since they are blueprints and not provisioned

CI/CD Integration

Users can now separate apply and destroy workflows:

# Get modified components (for apply)
atmos describe affected --query '[.[] | select(.deleted != true)]'

# Get deleted components (for destroy)
atmos describe affected --query '[.[] | select(.deleted == true)]'

Test Coverage

• 8 unit tests for deletion detection logic covering:

  • Component deleted from stack
  • Entire stack deleted
  • Abstract components not reported
  • Stack filter support
  • Multiple component types
  • Edge cases (no components section, no deletions)

• 2 integration tests using new fixture:

  • TestDescribeAffectedDeletedComponentDetection
  • TestDescribeAffectedDeletedComponentFiltering

references

• PRD: docs/prd/describe-affected-deleted-detection.md
• Related to CI/CD simplification initiative on roadmap

Summary by CodeRabbit

• New Features

  • Detects deleted components and stacks in describe-affected; adds two output fields: deleted and deletion_type.

• Documentation

  • Added PRD, blog post, CLI docs and CI/CD examples describing deleted-detection and destruction workflows.

• Tests

  • Added unit/integration tests and fixtures covering deletion scenarios, filtering, and abstract-component behavior.

• Chores

  • Bumped toolchain/dependencies and refreshed NOTICE license entries.

• Mocks

  • Added telemetry mock method to support feature-flag checks.

• Errors

  • Introduced a new sentinel error for no stack manifests found.

• Add env map support at workflow and step levels in workflow YAML files
• Environment variables are merged hierarchically with step-level overriding workflow-level for the same keys
• Support inheritance pattern where different keys from workflow and step levels are both available to the command

why

• Users need the ability to define common environment variables at the workflow level
• Step-level env vars allow overriding workflow defaults for specific steps
• Hierarchical merging provides a flexible, intuitive interface consistent with how stack fields work

references

• Enables user feature request for workflow environment variable support
• Follows existing hierarchical pattern used for stack field overrides

Summary by CodeRabbit

• New Features

  • Workflow- and step-scoped environment maps added; variables merge hierarchically with step values taking precedence and identity/auth vars appended.

• Bug Fixes

  • Environment preparation now always starts from the system/global base environment and consistently preserves/merges it across steps.

• Documentation

  • CLI docs and a new blog post describe merge order, scoping, and precedence.

• Tests

  • Expanded unit and fixture tests covering merge, precedence, override, scoping, and auth interactions; tests now validate dynamic environment composition.

• Promote 6 key authentication milestones to featured status: atmos auth command framework, AWS SSO, GitHub OIDC, keyring backends, zero-config SSO, and automatic ECR authentication
• Remove planned Vault integration milestone from roadmap
• Update secrets-management initiative to shipped status (100% progress)

why

Vault integration is not planned for the Atmos product. The promoted auth milestones represent core shipped features that should be highlighted as featured accomplishments on the public roadmap.

references

N/A

Summary by CodeRabbit

• Documentation
  • Updated product roadmap with improved prioritization and categorization for greater visibility.
  • Marked Secrets Management and Secrets Masking initiatives as shipped and complete.
  • Removed Vault integration milestone from Secrets Management roadmap.

• Fixed EvaluateYqExpression to correctly handle YAML strings ending with colons (e.g., AWS ARNs like arn:aws:secretsmanager:...:password::)
• Added isScalarString pre-check to detect strings ending with colons before YAML parsing
• Added isMisinterpretedScalar post-check to detect when YAML parser converts a scalar string into a map with null value
• Added comprehensive test coverage (improved from 27.9% to 76.9%)

why

• The !terraform.state YAML tag was incorrectly parsing Terraform output values ending with colons (: or ::), converting them from strings into nested map structures
• This caused Terraform validation errors when variables were defined as map(string) but received objects instead
• AWS Secrets Manager ARNs require trailing :: for JSON key access with default version, making this a common issue for ECS task definitions

references

• Closes #2031

Summary by CodeRabbit

• Bug Fixes
  • Improved YAML parsing to correctly handle string values with special characters (such as trailing colons) that were previously misinterpreted as complex data structures.