github cloudposse/atmos v1.221.0-rc.4

pre-release5 hours ago

🚀 Enhancements

fix(pro): respect metadata.enabled when uploading instances for drift @osterman (#2563) ## what
  • atmos list instances --upload now collapses the Atmos Pro enabled hierarchy (metadata.enabled > settings.pro.enabled > settings.pro.drift_detection.enabled) before uploading, so the values Atmos Pro persists already reflect any outer disable.
  • A shared effectiveEnabledState helper is the single source of truth for both the upload payload (extractProSettings) and the success-toast counts, so they can no longer diverge.
  • Disabled components are still uploaded (as pro.enabled: false) rather than omitted, so Atmos Pro shows them disabled instead of orphaning them.
  • Reference docs corrected (settings/pro.mdx gains a settings.pro.enabled entry + precedence note; list/list-instances.mdx drops the now-false "preserved verbatim" / "drift is independent of pro.enabled" claims), plus a docs/fixes/ write-up.

why

  • Components disabled upstream via metadata.enabled: false kept failing scheduled drift detection (dispatchError: "missing_plan_result", drift_status: error): the CLI skips planning them, but the upload serialized the raw settings.pro block and never sent metadata.enabled, so Atmos Pro (whose ingestion contract has no metadata field) persisted them as enabled:true, drift_enabled:true and legitimately dispatched drift.
  • Fixing it in the CLI keeps the determination where it is already resolved and needs no Atmos Pro change: the stuck error rows self-heal to disabled on the next upload, with no data migration.
  • pro.enabled defaults to true (matching the Pro server-side default) so the collapse only ever turns things off when an outer level is explicitly disabled — it never regresses default-enabled components.

references

  • docs/fixes/2026-06-03-drift-dispatch-ignores-metadata-enabled.md (root-cause analysis, Neon instances evidence, verification steps)
  • Source of truth for the disabled determination: internal/exec/component_utils.go (isComponentEnabled)

Summary by CodeRabbit

  • Bug Fixes

    • Resolve upload so component enablement honors metadata.enabled, preventing metadata-disabled components from remaining scheduled for drift and correcting counts; disabled components are uploaded as disabled rather than omitted.
  • Documentation

    • Clarify enablement precedence (metadata.enabled > settings.pro.enabled > drift_detection.enabled), upload behavior, and how effective Pro/drift state is reflected in UI counts.
  • Tests

    • Add unit and end-to-end tests validating effective enablement resolution, drift counting, and uploaded payloads.
fix(auth): deduplicate ECR, ECR Public, and EKS integrations to once per process @MrZablah (#2564) ## What

Adds a process-level execution cache to triggerIntegrations so that
auto-provisioned integrations (aws/ecr, aws/ecr-public, aws/eks)
fire at most once per atmos invocation, regardless of how many times
Authenticate is called or how many AuthManager instances are created.

The cache key is the integration's canonical target endpoint rather than
its config entry name:

  • aws/ecr"aws/ecr:<account_id>:<region>"
  • aws/ecr-public"aws/ecr-public" (single global registry)
  • aws/eks"aws/eks:<cluster_name>:<region>"
  • everything else → integration name (no behaviour change)

This means two config entries that point at the same registry — e.g. one
from global atmos.yaml and one from a component stack file — are
collapsed to a single execution.

Why

atmos terraform plan calls Authenticate from at least three internal
paths: setupTerraformAuth, TerraformPreHook, and one call per YAML
function (!store.get, !terraform.state). With a 6-tool .tool-versions
this produced 6 ECR logins per command. Switching to a name-keyed cache
reduced it to 2 because merged configs can carry two integration entries
with different names for the same registry. Keying by target endpoint
reduces this to exactly 1.

Changes

  • pkg/auth/manager_integrations.go — adds processIntegrationCache sync.Map, resetProcessIntegrationCache() (test helper),
    integrationTargetKey() (canonical key helper covering aws/ecr,
    aws/ecr-public, aws/eks); updates triggerIntegrations to use
    LoadOrStore on the target key.
  • pkg/auth/manager_integrations_test.go — adds
    TestIntegrationTargetKey (table-driven tests for all key variants
    including ECR Public) and TestIntegrationTargetKey_Deduplication
    (verifies that two same-registry entries produce one cache hit).

Notes

aws/ecr-public was added to upstream/main in #2231 after this branch
diverged; coverage for it was added here to keep deduplication consistent
across all three AWS integration kinds.

references

ECR / ECR Public Login Executes Multiple Times Per atmos terraform Invocation
#2562

Summary by CodeRabbit

  • New Features

    • Added process-level deduplication for auto-provisioned integrations to prevent redundant provisioning of the same target within a single process.
    • Failed provisioning attempts are evicted from the dedupe cache so retries can proceed.
  • Tests

    • Added unit tests validating cache key behavior and deduplication scenarios to ensure consistent provisioning outcomes.

Don't miss a new atmos release

NewReleases is sending notifications on new releases.