Update atmos terraform generate planfile and atmos terraform plan-diff commands. Update depends_on for component dependencies
#1405
Conversation
|
Warning This PR exceeds the recommended limit of 1,000 lines.Large PRs are difficult to review and may be rejected due to their size. Please verify that this PR does not address multiple issues. |
|
Important Cloud Posse Engineering Team Review RequiredThis pull request modifies files that require Cloud Posse's review. Please be patient, and a core maintainer will review your changes. To expedite this process, reach out to us on Slack in the |
📝 WalkthroughWalkthroughRemoves a repo dotfile, adds ignore rules, bumps Go dependencies, adds an error sentinel, introduces a component lock helper and tests, tightens describe-dependents exec with a constructor and stack gating, propagates template/function flags into planfile flows, adds Context.Stack, updates Docker/CI version, expands many test fixtures, and updates docs. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI
participant DescribeExec
participant Config
participant Stacks
User->>CLI: atmos describe dependents
CLI->>DescribeExec: NewDescribeDependentsExec(atmosConfig)
DescribeExec->>DescribeExec: Validate atmosConfig (nil -> ErrAtmosConfigIsNil)
DescribeExec->>Stacks: ExecuteDescribeStacks(...)
Stacks-->>DescribeExec: Components by stack
DescribeExec->>DescribeExec: Filter dependents by depends_on.stack / same-stack rules
DescribeExec-->>CLI: Dependents list
CLI-->>User: Output dependents
sequenceDiagram
participant User
participant CLI
participant PlanGen
participant Config
participant TF
User->>CLI: atmos terraform generate planfile
CLI->>PlanGen: ExecuteTerraformGeneratePlanfile(options)
PlanGen->>Config: InitCliConfig(with ProcessTemplates/ProcessFunctions from flags)
PlanGen->>Config: ProcessStacks(templates/functions, skip flags)
PlanGen->>TF: terraform plan -out=...
TF-->>PlanGen: Planfile
PlanGen-->>User: Path to planfile
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. 📜 Recent review detailsConfiguration used: .coderabbit.yaml 💡 Knowledge Base configuration:
You can enable these sources in your CodeRabbit configuration. 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (2)
website/docs/cli/commands/describe/describe-dependents.mdx (2)
196-201: Fix mismatched stack_slug in example (test-1 vs dev).stack_slug should reflect the same stack as the surrounding example (tenant1-ue2-test-1).
- "stack_slug": "tenant1-ue2-dev-top-level-component1", + "stack_slug": "tenant1-ue2-test-1-top-level-component1",
333-349: Fix stack_slug values to match their stacks.
- Entry 1 uses the test-1 stack; adjust slug accordingly.
- Entry 2 uses the dev stack; slug should use dev (not test-1).
- "stack_slug": "tenant1-ue2-dev-top-level-component2", + "stack_slug": "tenant1-ue2-test-1-top-level-component2", @@ - "stack_slug": "tenant1-ue2-test-1-top-level-component1", + "stack_slug": "tenant1-ue2-dev-top-level-component1",
🧹 Nitpick comments (21)
internal/exec/component_utils.go (2)
18-27: Simplify isComponentLocked and fix trailing dot in the reference link
- The nested conditional can be flattened.
- Drop the trailing period in the URL to avoid a broken link.
Apply:
-// isComponentLocked checks if a component is locked based on its metadata. -// https://atmos.tools/core-concepts/stacks/define-components/#locking-components-with-metadatalocked. +// isComponentLocked checks if a component is locked based on its metadata. +// https://atmos.tools/core-concepts/stacks/define-components/#locking-components-with-metadatalocked func isComponentLocked(metadataSection map[string]any) bool { - if locked, ok := metadataSection["locked"].(bool); ok { - if locked { - return true - } - } - return false + if locked, ok := metadataSection["locked"].(bool); ok { + return locked + } + return false }
18-27: Optional: parity with isComponentEnabled loggingConsider adding a debug log when a component is locked (for symmetry with isComponentEnabled). This would require passing componentName to isComponentLocked, so treat as an optional refactor to avoid ripple effects now.
tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/mixins/region/us-west-2.yaml (1)
3-5: Confirm environment placement: vars.environment vs settings.context.environmentIn this scenario mixin, environment is under vars (environment: uw2), while in the template-based scenario, environment is set via settings.context.environment. If the depends_on logic or stack slug generation relies on Context.Environment, consider mirroring that here to avoid subtle test differences.
If alignment is desired, you could add context without removing vars:
vars: region: us-west-2 - environment: uw2 + environment: uw2 +settings: + context: + environment: uw2Please confirm which placement the tests expect. If this difference is intentional to exercise both code paths, ignore this suggestion.
tests/fixtures/scenarios/atmos-describe-affected/stacks/deploy/nonprod.yaml (1)
14-18: Template expansion will produce strings; confirm downstream expectationsfoo/bar/baz now render from settings a/b/c via templates. With the quotes present, these will be strings ("1","2","3"). If any consumer expects numeric types, you may want to coerce or remove quotes and cast during templating.
Two options if numeric types are desired:
- Keep quoting and cast explicitly:
- foo: "{{ .settings.a }}" - bar: "{{ .settings.b }}" - baz: "{{ .settings.c }}" + foo: "{{ .settings.a | int }}" + bar: "{{ .settings.b | int }}" + baz: "{{ .settings.c | int }}"
- Or drop quotes to allow YAML numeric scalars after template rendering (ensure your linting tolerates unquoted templates):
- foo: "{{ .settings.a }}" - bar: "{{ .settings.b }}" - baz: "{{ .settings.c }}" + foo: {{ .settings.a }} + bar: {{ .settings.b }} + baz: {{ .settings.c }}If strings are intended, current changes are perfect.
errors/errors.go (1)
65-67: Add a short doc comment for the new exported sentinel.Exported identifiers should have a GoDoc comment to satisfy linters and improve discoverability.
Apply:
- ErrAtmosConfigIsNil = errors.New("atmos config is nil") + // ErrAtmosConfigIsNil is returned when an AtmosConfiguration pointer is unexpectedly nil. + ErrAtmosConfigIsNil = errors.New("atmos config is nil")internal/exec/component_utils_test.go (2)
151-156: Fix the test failure message to reference the correct function.The error message mentions isComponentEnabled instead of isComponentLocked.
- t.Errorf("isComponentEnabled() = %v, want %v", got, tt.want) + t.Errorf("isComponentLocked() = %v, want %v", got, tt.want)
105-149: Optional: add case-sensitivity coverage for the 'locked' key.We have thorough value-type coverage; consider adding a test where "LOCKED" or "LoCkEd" is present to assert only the exact "locked" boolean true is honored (mirroring the enabled case-sensitivity tests).
Happy to draft the additional table entries if you want.
internal/exec/terraform_generate_planfile.go (1)
22-23: Nit: error name casing is inconsistent (“Json”).Consider renaming to ErrGettingJSONForPlanfile for consistency with common initialism casing.
tests/fixtures/scenarios/depends-on-with-stacks-name-template/atmos.yaml (1)
19-21: Confirm log level casing.Some parsers expect lowercase levels. If Atmos only accepts lowercase, switch Info -> info.
Apply if needed:
logs: file: "/dev/stderr" - level: Info + level: infowebsite/docs/core-concepts/stacks/dependencies.mdx (3)
17-20: Tighten the intro to avoid repetition.Reduce repeated “it’s important” phrasing.
-Before deploying components, it's important to consider the dependencies between components. -For example, a database component might depend on a network component. -When this happens, it's important to ensure that the network component is deployed before the database component. +Before deploying, consider component dependencies. +For example, a database might depend on a network; ensure the network is deployed first.
35-37: Grammar: remove redundant conjunction.“However … so we decided” uses two conjunctions; keep one.
-However, since it’s not clear how lists should be -deep-merged, so we decided to convert it to a map instead. In this map, the keys are lexicographically ordered, and +However, since it’s not clear how lists should be deep-merged, we decided to convert it to a map instead. +In this map, the keys are lexicographically ordered, and
70-71: Style: “other than” → “different from”.More concise.
-If `component` is specified, you can provide the other context variables to define an Atmos stack other than the current stack. +If `component` is specified, you can provide the other context variables to define an Atmos stack different from the current stack.website/docs/cli/commands/describe/describe-dependents.mdx (1)
37-41: Document stack precedence here as well.Add a note that stack, when provided, takes precedence and other context attributes are ignored (to match core concepts doc).
<dt>stack <em>(optional)</em></dt> <dd>Atmos stack where the `component` is provisioned</dd> - <dt>namespace <em>(optional)</em></dt> + :::info + If `stack` is specified, it is processed first and the `namespace`, `tenant`, `environment`, and `stage` attributes are ignored. + ::: + + <dt>namespace <em>(optional)</em></dt>tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/deploy/prod/us-west-2.yaml (2)
23-25: Nit: comment grammar (“component” vs “components”).Minor wording correction in the comment.
Apply:
- # `tgw/attachment` depends on the `tgw/hub` components in the `network` account in `us-east-1` region + # `tgw/attachment` depends on the `tgw/hub` component in the `network` account in the `us-east-1` region
7-18: Optional: add a test asserting other fields are ignored when ‘stack’ is set.To harden precedence behavior, consider a test case where both stack and other selectors are provided, and assert only stack is honored. No fixture change needed; just an additional unit test.
I can draft the test scaffolding if helpful.
tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/deploy/network/us-west-2.yaml (1)
23-25: Optional: be explicit about stage for readability.Not required (current stage is inherited), but adding stage: network could make intent unambiguous to readers.
component: tgw/hub environment: ue1 + stage: networktests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/deploy/prod/us-east-1.yaml (1)
23-25: Nit: comment grammar (“component” singular).- # `tgw/attachment` depends on the `tgw/hub` component in the same region in the `network` account + # `tgw/attachment` depends on the `tgw/hub` component in the same region in the `network` accounttests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/deploy/network/us-east-1.yaml (1)
19-23: Clarify the intent in the comment.Consider noting that the explicit stack template resolves to the current stack to make the test’s purpose obvious.
- # `tgw/hub` depends on the `vpc` component in the same stack (same account, same region) + # `tgw/hub` depends on the `vpc` component in the same stack (same account, same region) — + # stack is explicitly set via template to the current stack to exercise stack templatinginternal/exec/describe_dependents_test.go (1)
288-462: Optional: reduce duplication by extracting a helper to run the matrixBoth new tests share identical setup/teardown and execution patterns. Consider a small helper that accepts workDir and the cases slice to DRY up the tests. Keeps future maintenance cheaper without changing semantics.
Also applies to: 464-658
internal/exec/describe_dependents.go (2)
283-284: Use strings.ReplaceAll for clarityReplaceAll is clearer than Replace with -1.
- StackSlug: fmt.Sprintf("%s-%s", stackName, strings.Replace(stackComponentName, "/", "-", -1)), + StackSlug: fmt.Sprintf("%s-%s", stackName, strings.ReplaceAll(stackComponentName, "/", "-")),
108-121: Optional: wrap upstream errors with contextReturning raw errors from ExecuteDescribeStacks / ExecuteDescribeComponent makes debugging harder. Consider wrapping with context.
For example:
- return fmt.Errorf("describe stacks: %w", err)
- return fmt.Errorf("describe component %q in stack %q: %w", component, stack, err)
Also applies to: 124-141
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (39)
.cursor/.cursor(0 hunks).dockerignore(1 hunks).gitignore(1 hunks)errors/errors.go(1 hunks)examples/quick-start-advanced/Dockerfile(1 hunks)go.mod(5 hunks)internal/exec/component_utils.go(1 hunks)internal/exec/component_utils_test.go(1 hunks)internal/exec/describe_dependents.go(4 hunks)internal/exec/describe_dependents_test.go(2 hunks)internal/exec/terraform_generate_planfile.go(1 hunks)internal/exec/terraform_plan_diff_preparation.go(2 hunks)pkg/schema/schema.go(1 hunks)tests/fixtures/scenarios/atmos-describe-affected/atmos.yaml(1 hunks)tests/fixtures/scenarios/atmos-describe-affected/stacks/deploy/nonprod.yaml(1 hunks)tests/fixtures/scenarios/atmos-describe-affected/stacks/deploy/prod.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/atmos.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/deploy/network/us-east-1.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/deploy/network/us-west-2.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/deploy/prod/us-east-1.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/deploy/prod/us-west-2.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/mixins/region/us-east-1.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/mixins/region/us-west-2.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/mixins/stage/network.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/mixins/stage/prod.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-template/atmos.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/deploy/network/us-east-1.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/deploy/network/us-west-2.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/deploy/prod/us-east-1.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/deploy/prod/us-west-2.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/mixins/region/us-east-1.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/mixins/region/us-west-2.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/mixins/stage/network.yaml(1 hunks)tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/mixins/stage/prod.yaml(1 hunks)tests/fixtures/scenarios/terraform-generate-planfile/stacks/deploy/nonprod.yaml(1 hunks)website/docs/cli/commands/describe/describe-dependents.mdx(1 hunks)website/docs/cli/commands/version.mdx(1 hunks)website/docs/core-concepts/stacks/dependencies.mdx(2 hunks)website/docs/integrations/atlantis.mdx(1 hunks)
💤 Files with no reviewable changes (1)
- .cursor/.cursor
🧰 Additional context used
📓 Path-based instructions (4)
**/*.go
📄 CodeRabbit Inference Engine (.cursor/rules/atmos-rules.mdc)
**/*.go: Use Viper for managing configuration, environment variables, and flags
Use interfaces for external dependencies to facilitate mocking
All code must pass golangci-lint checks
Follow Go's error handling idioms
Use meaningful error messages
Wrap errors with context using fmt.Errorf("context: %w", err)
Consider using a custom error type for domain-specific errors
Follow standard Go coding style
Use gofmt and goimports to format code
Prefer short, descriptive variable names
Use snake_case for environment variables
Document all exported functions, types, and methods
Document complex logic with inline comments
Follow Go's documentation conventions
Use Viper for configuration management
Support configuration via files, environment variables, and flags
Follow the precedence order: flags > environment variables > config file > defaults
Files:
pkg/schema/schema.gointernal/exec/component_utils_test.gointernal/exec/component_utils.goerrors/errors.gointernal/exec/terraform_generate_planfile.gointernal/exec/terraform_plan_diff_preparation.gointernal/exec/describe_dependents.gointernal/exec/describe_dependents_test.go
**/*_test.go
📄 CodeRabbit Inference Engine (.cursor/rules/atmos-rules.mdc)
**/*_test.go: Every new feature must include comprehensive unit tests
Test both happy paths and error conditions
Use table-driven tests for testing multiple scenarios
Include integration tests for command flows
Test CLI end-to-end when possible
Use test fixtures for complex inputs
Consider using testify/mock for creating mock implementations
Files:
internal/exec/component_utils_test.gointernal/exec/describe_dependents_test.go
website/**
📄 CodeRabbit Inference Engine (.cursor/rules/atmos-rules.mdc)
website/**: Update website documentation in the website/ directory when adding new features
Follow the website's documentation structure and style
Keep website code in the website/ directory
Follow the existing website architecture and style
Document new features on the website
Include examples and use cases in website documentation
Files:
website/docs/integrations/atlantis.mdxwebsite/docs/cli/commands/describe/describe-dependents.mdxwebsite/docs/cli/commands/version.mdxwebsite/docs/core-concepts/stacks/dependencies.mdx
go.mod
📄 CodeRabbit Inference Engine (.cursor/rules/atmos-rules.mdc)
Manage dependencies with Go modules
Files:
go.mod
🧠 Learnings (16)
📓 Common learnings
Learnt from: Listener430
PR: cloudposse/atmos#934
File: tests/fixtures/scenarios/docs-generate/README.md.gotmpl:99-118
Timestamp: 2025-01-25T03:51:57.689Z
Learning: For the cloudposse/atmos repository, changes to template contents should be handled in dedicated PRs and are typically considered out of scope for PRs focused on other objectives.
Learnt from: aknysh
PR: cloudposse/atmos#944
File: go.mod:206-206
Timestamp: 2025-01-17T00:18:57.769Z
Learning: For indirect dependencies with license compliance issues in the cloudposse/atmos repository, the team prefers to handle them in follow-up PRs rather than blocking the current changes, as these issues often require deeper investigation of the dependency tree.
📚 Learning: 2024-11-12T03:15:15.627Z
Learnt from: aknysh
PR: cloudposse/atmos#775
File: examples/quick-start-advanced/Dockerfile:9-9
Timestamp: 2024-11-12T03:15:15.627Z
Learning: It is acceptable to set `ARG ATMOS_VERSION` to a future version like `1.105.0` in `examples/quick-start-advanced/Dockerfile` if that will be the next release.
Applied to files:
website/docs/integrations/atlantis.mdxexamples/quick-start-advanced/Dockerfile
📚 Learning: 2024-11-23T00:13:22.004Z
Learnt from: osterman
PR: cloudposse/atmos#801
File: examples/quick-start-advanced/Dockerfile:9-9
Timestamp: 2024-11-23T00:13:22.004Z
Learning: When updating the `ATMOS_VERSION` in Dockerfiles, the team prefers to pin to the next future version when the PR merges, even if the version is not yet released.
Applied to files:
website/docs/integrations/atlantis.mdxexamples/quick-start-advanced/Dockerfile
📚 Learning: 2024-11-25T17:17:15.703Z
Learnt from: RoseSecurity
PR: cloudposse/atmos#797
File: pkg/list/atmos.yaml:213-214
Timestamp: 2024-11-25T17:17:15.703Z
Learning: The file `pkg/list/atmos.yaml` is primarily intended for testing purposes.
Applied to files:
tests/fixtures/scenarios/depends-on-with-stacks-name-template/atmos.yamltests/fixtures/scenarios/atmos-describe-affected/stacks/deploy/prod.yamltests/fixtures/scenarios/depends-on-with-stacks-name-pattern/atmos.yaml
📚 Learning: 2025-01-25T03:51:57.689Z
Learnt from: Listener430
PR: cloudposse/atmos#934
File: tests/fixtures/scenarios/docs-generate/README.md.gotmpl:99-118
Timestamp: 2025-01-25T03:51:57.689Z
Learning: For the cloudposse/atmos repository, changes to template contents should be handled in dedicated PRs and are typically considered out of scope for PRs focused on other objectives.
Applied to files:
tests/fixtures/scenarios/depends-on-with-stacks-name-template/atmos.yamltests/fixtures/scenarios/atmos-describe-affected/atmos.yaml
📚 Learning: 2024-12-12T15:17:45.245Z
Learnt from: osterman
PR: cloudposse/atmos#808
File: examples/demo-atmos.d/atmos.d/tools/helmfile.yml:10-10
Timestamp: 2024-12-12T15:17:45.245Z
Learning: In `examples/demo-atmos.d/atmos.d/tools/helmfile.yml`, when suggesting changes to `kubeconfig_path`, ensure that the values use valid Go template syntax.
Applied to files:
tests/fixtures/scenarios/depends-on-with-stacks-name-template/atmos.yamltests/fixtures/scenarios/atmos-describe-affected/atmos.yaml
📚 Learning: 2025-03-18T12:26:25.329Z
Learnt from: Listener430
PR: cloudposse/atmos#1149
File: tests/snapshots/TestCLICommands_atmos_vendor_pull_ssh.stderr.golden:7-7
Timestamp: 2025-03-18T12:26:25.329Z
Learning: In the Atmos project, typos or inconsistencies in test snapshot files (such as "terrafrom" instead of "terraform") may be intentional as they capture the exact output of commands and should not be flagged as issues requiring correction.
Applied to files:
tests/fixtures/scenarios/depends-on-with-stacks-name-template/atmos.yamltests/fixtures/scenarios/depends-on-with-stacks-name-pattern/atmos.yaml
📚 Learning: 2024-12-01T00:33:20.298Z
Learnt from: aknysh
PR: cloudposse/atmos#810
File: examples/tests/stacks/catalog/terraform/template-functions-test2/defaults.yaml:28-32
Timestamp: 2024-12-01T00:33:20.298Z
Learning: In `examples/tests/stacks/catalog/terraform/template-functions-test2/defaults.yaml`, `!exec atmos terraform output` is used in examples to demonstrate its usage, even though `!terraform.output` is the recommended approach according to the documentation.
Applied to files:
tests/fixtures/scenarios/depends-on-with-stacks-name-template/atmos.yamltests/fixtures/scenarios/atmos-describe-affected/atmos.yaml
📚 Learning: 2025-07-05T20:59:02.914Z
Learnt from: aknysh
PR: cloudposse/atmos#1363
File: internal/exec/template_utils.go:18-18
Timestamp: 2025-07-05T20:59:02.914Z
Learning: In the Atmos project, gomplate v4 is imported with a blank import (`_ "github.com/hairyhenderson/gomplate/v4"`) alongside v3 imports to resolve AWS SDK version conflicts. V3 uses older AWS SDK versions that conflict with newer AWS modules used by Atmos. A full migration to v4 requires extensive refactoring due to API changes and should be handled in a separate PR.
Applied to files:
tests/fixtures/scenarios/depends-on-with-stacks-name-template/atmos.yaml
📚 Learning: 2024-12-11T18:40:12.808Z
Learnt from: Listener430
PR: cloudposse/atmos#844
File: cmd/helmfile.go:37-37
Timestamp: 2024-12-11T18:40:12.808Z
Learning: In the atmos project, `cliConfig` is initialized within the `cmd` package in `root.go` and can be used in other command files.
Applied to files:
tests/fixtures/scenarios/depends-on-with-stacks-name-template/atmos.yaml
📚 Learning: 2024-10-20T13:12:46.499Z
Learnt from: haitham911
PR: cloudposse/atmos#736
File: pkg/config/const.go:6-6
Timestamp: 2024-10-20T13:12:46.499Z
Learning: In `cmd/cmd_utils.go`, it's acceptable to have hardcoded references to `atmos.yaml` in logs, and it's not necessary to update them to use the `CliConfigFileName` constant.
Applied to files:
tests/fixtures/scenarios/atmos-describe-affected/atmos.yaml
📚 Learning: 2024-10-23T21:36:40.262Z
Learnt from: osterman
PR: cloudposse/atmos#740
File: cmd/cmd_utils.go:340-359
Timestamp: 2024-10-23T21:36:40.262Z
Learning: In the Go codebase for Atmos, when reviewing functions like `checkAtmosConfig` in `cmd/cmd_utils.go`, avoid suggesting refactoring to return errors instead of calling `os.Exit` if such changes would significantly increase the scope due to the need to update multiple call sites.
Applied to files:
errors/errors.go
📚 Learning: 2025-06-23T02:14:30.937Z
Learnt from: aknysh
PR: cloudposse/atmos#1327
File: cmd/terraform.go:111-117
Timestamp: 2025-06-23T02:14:30.937Z
Learning: In cmd/terraform.go, flags for the DescribeAffected function are added dynamically at runtime when info.Affected is true. This is intentional to avoid exposing internal flags like "file", "format", "verbose", "include-spacelift-admin-stacks", "include-settings", and "upload" in the terraform command interface, while still providing them for the shared DescribeAffected function used by both `atmos describe affected` and `atmos terraform apply --affected`.
Applied to files:
internal/exec/terraform_generate_planfile.gointernal/exec/terraform_plan_diff_preparation.go
📚 Learning: 2024-12-07T16:16:13.038Z
Learnt from: Listener430
PR: cloudposse/atmos#825
File: internal/exec/helmfile_generate_varfile.go:28-31
Timestamp: 2024-12-07T16:16:13.038Z
Learning: In `internal/exec/helmfile_generate_varfile.go`, the `--help` command (`./atmos helmfile generate varfile --help`) works correctly without requiring stack configurations, and the only change needed was to make `ProcessCommandLineArgs` exportable by capitalizing its name.
Applied to files:
internal/exec/terraform_generate_planfile.go
📚 Learning: 2024-11-13T21:37:07.852Z
Learnt from: Cerebrovinny
PR: cloudposse/atmos#764
File: internal/exec/describe_stacks.go:289-295
Timestamp: 2024-11-13T21:37:07.852Z
Learning: In the `internal/exec/describe_stacks.go` file of the `atmos` project written in Go, avoid extracting the stack name handling logic into a helper function within the `ExecuteDescribeStacks` method, even if the logic appears duplicated.
Applied to files:
internal/exec/describe_dependents.gointernal/exec/describe_dependents_test.go
📚 Learning: 2025-07-01T02:22:25.901Z
Learnt from: CR
PR: cloudposse/atmos#0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-07-01T02:22:25.901Z
Learning: Applies to go.mod : Manage dependencies with Go modules
Applied to files:
go.mod
🧬 Code Graph Analysis (1)
internal/exec/describe_dependents_test.go (3)
pkg/schema/schema.go (2)
ConfigAndStacksInfo(458-535)Dependent(813-828)pkg/config/config.go (1)
InitCliConfig(25-62)internal/exec/describe_dependents.go (1)
ExecuteDescribeDependents(94-329)
🪛 LanguageTool
website/docs/core-concepts/stacks/dependencies.mdx
[grammar] ~8-~8: There might be a mistake here.
Context: ...rt File from '@site/src/components/File' import Intro from '@site/src/components/...
(QB_NEW_EN)
[grammar] ~9-~9: There might be a mistake here.
Context: ... Intro from '@site/src/components/Intro' import Terminal from '@site/src/componen...
(QB_NEW_EN)
[style] ~19-~19: This word has been used in one of the immediately preceding sentences. Using a synonym could make your text more interesting to read, unless the repetition is intentional.
Context: ...work component. When this happens, it's important to ensure that the network component is...
(EN_REPEATEDWORDS_IMPORTANT)
[style] ~70-~70: Consider using a more formal/concise alternative here.
Context: ...text variables to define an Atmos stack other than the current stack. For example, you ca...
(OTHER_THAN)
[grammar] ~81-~81: There might be a mistake here.
Context: ... stack (e.g. tenant1-ue2-dev) :::info If stack is specified, it's processed ...
(QB_NEW_EN)
[grammar] ~82-~82: There might be a mistake here.
Context: ...entandstage` attributes are ignored. ::: :::tip You can use [Atmos Stack Man...
(QB_NEW_EN)
[grammar] ~87-~87: There might be a mistake here.
Context: ...llowing you to provide the parameters to depends_on dynamically. ::: ## Exampl...
(QB_NEW_EN)
[grammar] ~88-~88: There might be a mistake here.
Context: ... parameters to depends_on dynamically. ::: ## Examples In the following examp...
(QB_NEW_EN)
[typographical] ~117-~117: Consider using a typographic opening quote here.
Context: ... as component1 component: "component2" 2: # `...
(EN_QUOTES)
[typographical] ~117-~117: Consider using a typographic close quote here.
Context: ...ent1 component: "component2" 2: #component1`...
(EN_QUOTES)
[typographical] ~121-~121: Consider using a typographic opening quote here.
Context: ...nd any tenant) component: "component3" stage: "prod" ...
(EN_QUOTES)
[typographical] ~121-~121: Consider using a typographic close quote here.
Context: ...ant`) component: "component3" stage: "prod" 3: ...
(EN_QUOTES)
[typographical] ~122-~122: Consider using typographic quotation marks here.
Context: ...ponent: "component3" stage: "prod" 3: # component1...
(EN_QUOTES)
[typographical] ~127-~127: Consider using a typographic opening quote here.
Context: ...ng` Atmos stack) component: "component4" tenant: "tenant1...
(EN_QUOTES)
[typographical] ~127-~127: Consider using a typographic close quote here.
Context: ...tack) component: "component4" tenant: "tenant1" ...
(EN_QUOTES)
[typographical] ~128-~128: Consider using a typographic opening quote here.
Context: ...onent: "component4" tenant: "tenant1" environment: "ue2" ...
(EN_QUOTES)
[typographical] ~128-~128: Consider using a typographic close quote here.
Context: ...component4" tenant: "tenant1" environment: "ue2" ...
(EN_QUOTES)
[typographical] ~129-~129: Consider using a typographic opening quote here.
Context: ...ant: "tenant1" environment: "ue2" stage: "staging" ...
(EN_QUOTES)
[typographical] ~129-~129: Consider using a typographic close quote here.
Context: ... "tenant1" environment: "ue2" stage: "staging" ...
(EN_QUOTES)
[typographical] ~130-~130: Consider using typographic quotation marks here.
Context: ... environment: "ue2" stage: "staging" 4: # component1...
(EN_QUOTES)
[typographical] ~134-~134: Consider using a typographic opening quote here.
Context: ...rod` Atmos stack component: "component5" stack: "tenant1-...
(EN_QUOTES)
[typographical] ~134-~134: Consider using a typographic close quote here.
Context: ...stack component: "component5" stack: "tenant1-ue2-prod" ...
(EN_QUOTES)
[typographical] ~135-~135: Consider using a typographic opening quote here.
Context: ...ponent: "component5" stack: "tenant1-ue2-prod" 5: ...
(EN_QUOTES)
[typographical] ~135-~135: Consider using a typographic close quote here.
Context: ...t5" stack: "tenant1-ue2-prod" 5: # component1...
(EN_QUOTES)
[typographical] ~139-~139: Consider using a typographic opening quote here.
Context: ...same Atmos stack component: "component6" stack: "{{ .vars...
(EN_QUOTES)
[typographical] ~139-~139: Consider using a typographic close quote here.
Context: ...stack component: "component6" stack: "{{ .vars.tenant }}-...
(EN_QUOTES)
[typographical] ~140-~140: Consider using a typographic opening quote here.
Context: ...ponent: "component6" stack: "{{ .vars.tenant }}-{{ .vars.environment ...
(EN_QUOTES)
[typographical] ~144-~144: Consider using a typographic close quote here.
Context: ...nment component: "component7" stack: "{{ .vars.tenant }}-...
(EN_QUOTES)
[typographical] ~145-~145: Consider using a typographic opening quote here.
Context: ...ponent: "component7" stack: "{{ .vars.tenant }}-uw2-{{ .vars.stage }}...
(EN_QUOTES)
[grammar] ~191-~191: There might be a mistake here.
Context: ...ent: "uw2" stage: "dev" components: terraform: vpc: vars: ...
(QB_NEW_EN)
[grammar] ~269-~269: There might be a mistake here.
Context: ...nts](/cli/commands/describe/dependents) and [atmos describe affected`](/cli/com...
(QB_NEW_EN)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (12)
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: Analyze (go)
- GitHub Check: Lint (golangci)
- GitHub Check: Build (ubuntu-latest, linux)
- GitHub Check: Build (windows-latest, windows)
- GitHub Check: Build (macos-latest, macos)
- GitHub Check: Lint (golangci)
- GitHub Check: Analyze (go)
- GitHub Check: Analyze (go)
- GitHub Check: Lint (golangci)
- GitHub Check: website-deploy-preview
- GitHub Check: Summary
🔇 Additional comments (40)
tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/mixins/stage/network.yaml (2)
3-5: LGTM: stage context mixin matches new depends_on semanticsUsing settings.context.stage here is consistent with the PR’s cross-stack dependency resolution and templated stack naming.
1-1: Schema directive consistent across mixinsAll
tests/fixtures/.../stacks/mixins/*.yamlfiles uniformly reference# yaml-language-server: $schema=https://atmos.tools/schemas/atmos/atmos-manifest/1.0/atmos-manifest.jsonNo mixin fixtures point to any other schema URL. Validation in editors/CI should pass as expected.
website/docs/integrations/atlantis.mdx (1)
676-676: ATMOS_VERSION bump to 1.187.0 looks good; confirm artifact availability at merge timeAligns with the team’s preference to pin to the upcoming release. Just ensure the GitHub release asset exists when this merges to avoid broken installation in the example workflow.
tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/mixins/stage/prod.yaml (1)
1-4: Prod stage mixin fixture — LGTMSchema header and stage value look correct for the scenario.
tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/mixins/region/us-west-2.yaml (1)
1-8: Region mixin adds uw2 environment via settings.context — verify intended precedenceUsing settings.context.environment here (uw2) while other scenarios set environment under vars is likely intentional to exercise templating resolution. Please confirm this difference is deliberate for the “name-template” scenario and that call sites read from settings.context as expected.
tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/mixins/region/us-east-1.yaml (1)
1-5: Region mixin fixture — LGTMConsistent schema header and values (us-east-1, ue1) for the “name-pattern” scenario.
.gitignore (1)
19-19: LGTM: Ignore Terraform planfile.json artifactsGood addition to keep generated planfile JSONs out of the repo. This matches the new planfile flows.
website/docs/cli/commands/version.mdx (1)
47-47: Docs tweak LGTMClearer wording and consistent punctuation for flag values.
tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/mixins/region/us-east-1.yaml (1)
6-8: LGTM: Region mixin sets context.environmentUsing settings.context.environment here makes sense for stack-aware dependency discovery.
examples/quick-start-advanced/Dockerfile (1)
9-9: All ATMOS_VERSION references updated to 1.187.0 – bump is consistentVerified locations:
- examples/quick-start-advanced/Dockerfile:
- Line 9:
ARG ATMOS_VERSION=1.187.0- Line 46:
RUN apt-get … atmos="${ATMOS_VERSION}-*"- website/docs/integrations/atlantis.mdx (around line 676):
ATMOS_VERSION: 1.187.0LGTM – approving these changes.
tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/mixins/stage/network.yaml (1)
1-4: Fixture looks correct for name_pattern scenario.Using vars.stage here complements the name-pattern scenario; it’s fine that the template scenario uses settings.context elsewhere.
.dockerignore (1)
17-17: Good call ignoring planfile artifacts.This will shrink Docker build contexts and avoid leaking generated planfile JSONs.
tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/mixins/stage/prod.yaml (1)
3-5: Fixture aligns with name_template scenario.Using settings.context.stage is appropriate here and exercises the alt code path compared to vars.stage.
pkg/schema/schema.go (1)
384-384: Context.Stack docs added and JSON schemas includestack
- Inline doc for
Context.Stackclarifies that it takes precedence over namespace/tenant/environment/stage during dependency resolution.- Verified in all public
atmos-manifest.jsonschemas (examples/*/schemas/…,tests/fixtures, andwebsite/static) that thestackproperty appears under thedepends_ondefinitions for editor validation/intellisense.All set—no further changes needed.
tests/fixtures/scenarios/atmos-describe-affected/atmos.yaml (1)
23-38: Enabling templates in this fixture looks good.Matches the PR intent to process templates/functions early and aligns with other scenarios. No issues spotted.
internal/exec/terraform_plan_diff_preparation.go (2)
91-95: Good: preserve ErrPlanHasDiff semantics.Using errors.Is against the sentinel ensures the plan-diff contract remains intact.
66-78: I dug into runTerraformInit and it explicitly unsets both flags before calling Terraform:initInfo := *info initInfo.SubCommand = "init" … initInfo.SkipInit = true initInfo.ProcessTemplates = false // ← here initInfo.ProcessFunctions = false // ← and here … return ExecuteTerraform(initInfo)So even if you pass a
planInfowith processing enabled, it’ll be turned off in init. The original suggestion to swap in&planInfowon’t actually change behavior. You’ll need to updaterunTerraformInititself if you want init to process templates/functions.— If init really must process templated backends or inputs, change those two lines to:
-initInfo.ProcessTemplates = false -initInfo.ProcessFunctions = false +initInfo.ProcessTemplates = info.ProcessTemplates +initInfo.ProcessFunctions = info.ProcessFunctionsand then pass through whatever flags you set on the caller side.
Likely an incorrect or invalid review comment.
tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/atmos.yaml (1)
1-22: Fixture aligns with name_pattern-driven stack slugs.This supports the new depends_on stack context and docs. Looks consistent with related stacks in this scenario.
tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/deploy/prod/us-east-1.yaml (1)
18-26: Ambiguous ‘network’ stack names under current name_patternThe
{environment}-{stage}pattern produces prod-network for both prod/us-east-1 and prod/us-west-2, so “network” isn’t unique. To exercise stack-over-stage precedence and avoid test ambiguity, explicitly specify one of the stacks in your fixture:• In tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/deploy/prod/us-east-1.yaml (lines 18-26), update the depends_on entry:
2: component: tgw/hub stage: network stack: prod-us-east-1 # explicit stack to disambiguate[optional_refactors_recommended]
tests/fixtures/scenarios/atmos-describe-affected/stacks/deploy/prod.yaml (1)
15-19: Good showcase of template evaluation from settings into vars.This directly exercises processing of templates/functions in manifests. Looks solid for the “describe affected” scenario.
internal/exec/terraform_generate_planfile.go (1)
116-119: Confirm default flags already true—no changes neededThe
--process-templatesand--process-functionsflags are registered as persistent flags on the rootterraformcommand (cmd/terraform_commands.go:275–276) with a default value oftrue. They automatically propagate to thegenerate planfilesubcommand, so:info.ProcessTemplates = options.ProcessTemplates info.ProcessFunctions = options.ProcessYamlFunctionsalready enables template and YAML-function processing by default. No forcing or flag-default changes are required here.
go.mod (1)
33-33: ✅ Dependency bumps look good; no strayreplacedirectives detected
- go.mod has two
requireblocks (lines 5, 93) and noreplaceentries.- Please run
go mod tidyand confirm there are no diffs.- Ensure
golangci-lintpasses as per repo policy.tests/fixtures/scenarios/terraform-generate-planfile/stacks/deploy/nonprod.yaml (1)
9-19: Great fixture to validate template/function processing during planfile generation.This will catch regressions where templates aren’t evaluated before plan generation. Looks good.
tests/fixtures/scenarios/depends-on-with-stacks-name-template/atmos.yaml (2)
17-17: Good use of stack name templating.The name_template aligns with the scenario’s intent and will exercise cross-stack resolution via settings.context.
34-37: Verify gomplate timeout units.Double-check whether timeout expects an integer seconds value or a duration string (e.g., "10s"). Adjust if the latter is required.
tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/deploy/prod/us-west-2.yaml (1)
18-26: Cross-stack dependency looks correct.Using environment: ue1 and stage: network without specifying tenant should default to the current tenant, matching the intended “network account in us-east-1” reference.
tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/deploy/network/us-west-2.yaml (1)
23-26: Confirm template alignment with stacks.name_template.The stack value "ue1-{{ .settings.context.stage }}" assumes stacks.name_template = "{{ .settings.context.environment }}-{{ .settings.context.stage }}". If that template changes (e.g., tenant added), these references must be updated to keep resolution working.
Also applies to: 33-35
tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/deploy/network/us-east-1.yaml (2)
14-22: Solid same-stack dependency fixtures.Both dependencies model within-stack ordering cleanly and align with the new depends_on semantics. Good coverage for the name-pattern scenario.
Also applies to: 27-33
3-5: Mixins for this scenario are present and correctly define context values
• tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/mixins/region/us-east-1.yaml
– region: us-east-1
– environment: ue1
• tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/mixins/stage/network.yaml
– stage: networkAll required context keys are set as expected.
tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/deploy/prod/us-west-2.yaml (1)
22-25: Good exercise of stack precedence (explicit cross-stack).Using stack: "ue1-network" tests the new precedence rule (stack takes priority over other context keys). This is exactly what we want to cover.
tests/fixtures/scenarios/depends-on-with-stacks-name-pattern/stacks/deploy/network/us-west-2.yaml (2)
18-25: Clear cross-region same-account dependency via environment.Good example of selecting the east region hub via environment without specifying stack. Matches the “no stack → use context selectors” rule.
31-35: Connector dependency looks consistent.Mirrors the attachment’s cross-region dependency; this should help validate fan-in dependents.
tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/deploy/prod/us-east-1.yaml (1)
23-25: Stack template correctly resolves to “ue1-network”
The region mixin attests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/mixins/region/us-east-1.yamlsets
.settings.context.environment: ue1, and the static suffix-networkproducesue1-network.
Describe-dependents tests (e.g.internal/exec/describe_dependents_test.golines 500–503) assert the stack as"ue1-network"withEnvironment: "ue1"andStage: "network". No changes needed.tests/fixtures/scenarios/depends-on-with-stacks-name-template/stacks/deploy/network/us-east-1.yaml (1)
19-23: Redundant but useful: explicit stack equals current stack.Specifying stack to the current stack (via template) is redundant, but it’s a good edge-case to ensure explicit stack doesn’t break same-stack dependencies. Keep it.
internal/exec/describe_dependents_test.go (4)
288-307: Good isolation of test environment and working directoryUsing t.Setenv and restoring CWD via t.Cleanup prevents cross-test interference and improves determinism.
458-460: ElementsMatch is the right choice for order-agnostic assertionsOrder-independent comparison for slices of struct is appropriate here.
Also applies to: 654-656
1-14: Imports look goodNew imports (os, require) are justified by the new tests.
455-456: VerifyatmosConfigdeclaration forExecuteDescribeDependentscallsI wasn’t able to confirm whether
atmosConfigin your internal tests is a value (schema.AtmosConfiguration) or already a pointer (*schema.AtmosConfiguration). Please double-check that you’re not passing a pointer-to-a-pointer:• internal/exec/describe_dependents_test.go:455–456
• internal/exec/describe_dependents_test.go:651–652If
atmosConfigis declared as a pointer, drop the extra ampersand:- res, err := ExecuteDescribeDependents(&atmosConfig, tc.component, tc.stack, false) + res, err := ExecuteDescribeDependents(atmosConfig, tc.component, tc.stack, false)Otherwise, if it’s a value, keep the ampersand.
internal/exec/describe_dependents.go (2)
48-57: Constructor wires dependencies cleanlyNewDescribeDependentsExec correctly injects ExecuteDescribeDependents, pager, TTY detection, and yq evaluator. Nice DI surface for testing.
100-103: Nil atmosConfig check is a good hard failReturning a sentinel for nil config prevents panics and clarifies caller errors.
|
These changes were released in v1.187.0. |
what
Update
atmos terraform generate planfileandatmos terraform plan-diffcommands. Process templates and Atmos YAML functions before executing the commands.Update
depends_onfor component dependencies. Addstackattribute as one of the context variables independs_onUpdate docs
Add tests
why
The
atmos terraform generate planfileandatmos terraform plan-diffcommands did not process temlates and Atmos YAML functions (they use the sameGocode), but they shouldAdd
stackattribute as one of the context variables independs_onto allow specifying an Atmos stack where the dependent component is provisioneddescription
Atmos supports configuring the relationships between components in the same or different stacks. You can define dependencies between components to ensure that components are deployed in the correct order.
You can define component dependencies by using the
settings.depends_onsection. The section used to define all the Atmos components (in the same or different stacks) that the current component depends on.The
settings.depends_onsection is a map of objects. The map keys are just the descriptions of dependencies and can be strings or numbers. Provide meaningful descriptions or numbering so that people can understand what the dependencies are about.If
componentis specified, you can provide the other context variables to define an Atmos stack other than the current stack.For example, you can specify:
stackif thecomponentis from a different Atmos stacknamespaceif thecomponentis from a different Organizationtenantif thecomponentis from a different Organizational Unitenvironmentif thecomponentis from a different regionstageif thecomponentis from a different accounttenant,environmentandstageif the component is from a different Atmos stack (e.g.tenant1-ue2-dev)NOTE:
If
stackis specified, it's processed first and thenamespace,tenant,environmentandstageattributes are ignored.NOTE:
You can use Atmos Stack Manifest Templating in
depends_on.Atmos processes the templates first, and then detects all the dependencies, allowing you to provide the parameters to
depends_ondynamically.In the following example, we specify that the
component1component depends on the following:component2component in the same Atmos stack ascomponent1component3component from theprodstagecomponent4component from thetenant1tenant,ue2environment andstagingstage (tenant1-ue2-stagingAtmos stack)component5component from thetenant1-ue2-prodAtmos stackcomponent6component from the same Atmos stack ascomponent1component7component from the same tenant and stage ascomponent1, butuw2environmentSpecifying
stackThe
stackattribute has higher precedence than the other context variables.If
stackis specified, thenamespace,tenant,environmentandstageattributes are ignored.As you can see in the examples above, we can use Atmos Stack Manifest Templating in the
stackattribute to dynamically specify the stack.This is useful when configuring
stacks.name_templateinatmos.yamlto define and refer to stacks. In this case, you can't use the context variablesnamespace,tenant,environmentandstageindepends_on.For example, in
atmos.yaml, we specifystacks.name_templateto define Atmos stacks, and enable templating:NOTE:
In this example, stacks are defined by the
settings.contextsection, notvars.In the
tenant1-uw2-devAtmos stack, we can use the followingdepends_onconfiguration to define the component dependencies:Execute the following Atmos commands to see the component dependencies:
> atmos describe dependents vpc -s tenant1-uw2-dev --pager off[ { "component": "tgw/attachment", "component_type": "terraform", "stack": "tenant1-uw2-dev", "stack_slug": "tenant1-uw2-dev-tgw-attachment" } ]> atmos describe dependents tgw/hub -s tenant1-ue1-dev --pager off[ { "component": "tgw/attachment", "component_type": "terraform", "stack": "tenant1-uw2-dev", "stack_slug": "tenant1-uw2-dev-tgw-attachment" }, { "component": "tgw/cross-region-hub-connector", "component_type": "terraform", "stack": "tenant1-uw2-dev", "stack_slug": "tenant1-uw2-dev-tgw-cross-region-hub-connector" } ]Summary by CodeRabbit
New Features
Documentation
Chores