cloudposse/atmos v1.220.0-rc.4

on GitHub

• Update atmos describe affected docs to lead with the new dependencies.components (kind: file|folder + path:) format for path-based dependencies; keep a short backward-compat note pointing to legacy settings.depends_on.
• Convert the dependents example on the describe affected page from settings.depends_on to dependencies.components.
• Correct the Merge Behavior section in stacks/dependencies/components.mdx: the default is replace, not append; append requires opting in via settings.list_merge_strategy: append. Add an "Opt-in append" subsection and link to the settings reference.
• Add a migration callout under the schema in stacks/dependencies/components.mdx clarifying that namespace/tenant/environment/stage are not supported in the new format — use a templated stack: instead.
• Rebalance stacks/dependencies/index.mdx so dependencies.tools and dependencies.components get equal billing in the intro, use cases, and component-dependencies subsection. Remove the duplicate Related Documentation entry and relabel the legacy link as "Legacy settings.depends_on". Add a link to atmos describe affected.
• Extend the Atmos manifest JSON Schema (website/static/schemas/... and the matching test fixture) so dependencies.components is allowed and validates component, stack, kind, path. Previously rejected by additionalProperties: false.

why

• The dedicated dependencies.components page existed, but the highest-traffic surface (describe affected) and the JSON Schema still only documented/allowed the legacy settings.depends_on map — driving users to the deprecated format and making the new format fail IDE/SchemaStore validation.
• The merge-behavior description in stacks/dependencies/components.mdx contradicted the announcement blog and the actual code (internal/exec/describe_dependents_test.go:1093–1154 confirms default = replace, append is opt-in via settings.list_merge_strategy). Users following the docs would have built a wrong mental model of inheritance.
• The migration story from settings.depends_on (with namespace/tenant/environment/stage) to dependencies.components (with templated stack:) was only discoverable via the migration table at the bottom of the page; surfacing it as a callout reduces confusion for users porting existing configs.

references

• pkg/schema/dependencies.go — canonical field set for dependencies.components
• internal/exec/describe_dependents_test.go:1093–1154 — confirms default merge is replace, append requires settings.list_merge_strategy: append
• website/blog/2026-03-14-dependencies-components.mdx — original announcement
• Verified: cd website && npm run build succeeds (no broken-link errors)

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Dependencies now support four top-level kinds: tools, components, files, and folders. Component-to-component relationships and explicit file/folder watch paths are first-class; describe-affected, describe-dependents, and CI workflows use the expanded surface while legacy formats remain supported.

• Documentation

  • Guides updated with examples, migration notes, canonical forms, merge semantics, and quick examples for cross-stack and path-based dependencies.

• Tests

  • Added coverage for the new surfaces, aliasing, deduplication, normalization, and v1/v2 equivalence.

• Replace the flaky upstream install_kustomize.sh script in the Dockerfile with a direct download from GitHub Releases, pinned to kustomize v5.8.1
• Replace mislav/bump-homebrew-formula-action@v3 with dawidd6/action-homebrew-bump-formula@v7 (SHA-pinned) for the Homebrew formula bump step

why

• The kustomize install script has known bugs (kubernetes-sigs/kustomize#5562) causing tar extraction failures (tar: ./kustomize_v*_linux_amd64.tar.gz: Cannot open) during Docker image builds
• The mislav/bump-homebrew-formula-action is broken because GitHub now returns HTTP 303 instead of 302 for tarball redirects, and the action hardcodes statusCode == 302 (mislav/bump-homebrew-formula-action#340, open/unfixed)
• Both failures blocked the v1.219.0 release workflow (run #26131090357)

references

• https://github.com/cloudposse/atmos/actions/runs/26131090357/job/77908154273
• mislav/bump-homebrew-formula-action#340
• kubernetes-sigs/kustomize#5562

Summary by CodeRabbit

• Chores
  • Updated build and deployment infrastructure, including CI/CD workflow configuration and Docker build process improvements for enhanced reliability and maintainability.

• Store hooks now fire when the stack is selected via the interactive prompt (not just when passed with -s).
• Store hooks can now read terraform outputs from S3 backends that require role assumption via assume_role.
• Auth context and auth manager from the main terraform execution are persisted and injected into PostRunE hook info so the hook's terraform output subprocess has the correct credentials.

why

Two bugs in the store hooks execution path caused hooks to silently fail in common scenarios:

1. Interactive stack selection lost for hooks (#2432): When a user runs atmos terraform apply component and selects the stack from the interactive prompt, the selected stack value was stored in the local info.Stack but never persisted to the Cobra flag set. PostRunE hooks re-parse args via ProcessCommandLineArgs, which reads from cmd.Flags().GetString("stack") — still empty. The hook silently skipped because it saw no stack. Fix: after the interactive prompt fills info.Stack, also set the Cobra flag via f.Value.Set(stack) so downstream consumers can read it.

2. Missing backend credentials for hook's terraform output (#2433): The store hook's terraform output subprocess needs credentials to access the S3 state backend, which often requires a chained role assumption (e.g., dev-role → tfstate-access-role). The main ExecuteTerraform sets up the full credential chain via setupTerraformAuth and prepareComponentExecution, but it takes info by value — the populated AuthContext and AuthManager don't flow back to the caller. The PostRunE hook creates a fresh info with nil auth fields, so the output subprocess fails with "No valid credential sources found". Fix: persist the auth context via SetLastAuthContext after prepareComponentExecution, and inject it into the hook's fresh info in runHooksWithOutput.

references

• Closes #2432
• Closes #2433
• Related: #2428 (original consolidated issue, closed in favor of #2432 and #2433)
• Related: #2357 (auth resolver injection for hooks)

Summary by CodeRabbit

• Bug Fixes

  • Post-run hooks now preserve Terraform auth so store hooks and hooks triggered after interactive stack selection work when role-assumption is required.

• Chores

  • Bumped Go to 1.26.3, upgraded many dependencies, updated NOTICE license listings, and advanced app version to 1.220.0.

• Tests

  • Added tests for interactive component/stack prompts and auth-context persistence.

• Documentation

  • Added two docs describing the store-hook role-assumption issue and interactive-prompt hook behavior.

• Stop atmos auth login from silently falling back to browser-based OAuth2 webflow when an aws/user identity HAS configured credentials but the keyring read fails (corrupted entry, missing fields, deserialization error, permission denied).
• Distinguish two failure modes in credentialsFromStore: ErrAwsUserNotConfigured (keyring miss — webflow remains an appropriate fallback) vs new ErrAwsUserKeyringReadFailed (keyring reachable but unreadable — webflow is now skipped so the real error surfaces).
• Promote the "starting browser-based authentication" message from Debug to Info and include a hint pointing at atmos auth user configure and webflow_enabled: false, so users see why the browser opened.
• Fix a latent realm bug in cmd/auth/user/configure.go: it was hardcoding store.Store(alias, creds, "") while the login resolver reads Retrieve(i.name, i.realm). With auth.realm or ATMOS_AUTH_REALM set, configure wrote one slot and login read another. Configure now computes the realm the same way pkg/auth/manager.go does.
• Add regression test TestUserIdentity_Authenticate_KeyringReadFailureSkipsWebflow that primes the keyring with an incomplete entry and asserts the webflow callback server is never reached. Tighten TestUser_credentialsFromStore to assert the specific sentinel returned in each path.
• Document the resolver order in website/docs/cli/configuration/auth/identities.mdx: clarify that Atmos does not consult ambient AWS credentials (env vars, ~/.aws/credentials, instance profiles) for aws/user, and call out the new keyring-read-failure diagnostic.

why

• Reported by Dan Miller in the Atmos community Slack: after upgrading past v1.214 he got redirected to the AWS sign-in browser flow even though he ran atmos auth user configure and "had access keys." The only working escape was credentials.webflow_enabled: false, which masked the real problem rather than fixing it.
• The webflow path introduced in #2148 (v1.215) was the right design — webflow is a legitimate authentication tier for IAM users — but the resolver collapsed every keyring failure into a single "not configured" error, so a corrupted/unreadable keyring entry looked identical to a fresh install and the browser flow fired. The browser flow then 400'd against the AWS sign-in token endpoint with no indication that the real failure was reading the keyring.
• Restoring the design invariant ("if creds are provided, use them; never silently bypass them with webflow") requires distinguishing the two failure modes. Once distinguished, webflow is correctly gated and the Info-level diagnostic tells the user what Atmos saw.
• The realm hardcode was not Dan's trigger (his realm resolved to "" on both sides) but is a real latent foot-gun for anyone using auth.realm for credential isolation — fixing it here closes the gap before another report arrives.

references

• Slack thread: original report from Dan Miller in cloudposse community Slack (no public issue).
• PR #2148 — original OAuth2 PKCE webflow introduction (commit 4e32b532f, shipped in v1.215).

Summary by CodeRabbit

• Bug Fixes

  • Credential configuration now resolves the auth realm so saved credentials go to the correct slot.
  • Keyring read failures (corrupted/unreadable entries) are reported and no longer silently fall back to browser auth; webflow is only used when credentials are genuinely absent.
  • Better distinction between missing credentials and unreadable keyring data.

• Documentation

  • Clarified browser-based fallback conditions and what counts as static AWS user credentials.

• Tests

  • Added regression tests to ensure keyring read failures skip webflow.