Add explicit stack name override via manifest 'name' field #1835
Conversation
Dependency Review✅ No vulnerabilities or license issues found.Scanned FilesNone |
Codecov Report❌ Patch coverage is
❌ Your patch check has failed because the patch coverage (78.04%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #1835 +/- ##
=======================================
Coverage 72.84% 72.85%
=======================================
Files 528 528
Lines 50539 50571 +32
=======================================
+ Hits 36816 36842 +26
- Misses 10953 10959 +6
Partials 2770 2770
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
Warning Rate limit exceeded@osterman has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 17 minutes and 37 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (16)
📝 WalkthroughWalkthroughAdds an explicit per-stack manifest Changes
Sequence Diagram(s)sequenceDiagram
participant CLI
participant DescribeStacks
participant ConfigAndStacksInfo
participant ComponentProcessors as (Terraform/Helmfile/Packer)
participant Workspace as TerraformWorkspace
CLI->>DescribeStacks: run describe stacks
DescribeStacks->>DescribeStacks: read stack manifest (includes optional `name`)
DescribeStacks->>ConfigAndStacksInfo: set StackManifestName := manifest.name (if present)
DescribeStacks->>ComponentProcessors: provide ConfigAndStacksInfo (with StackManifestName)
ComponentProcessors->>ComponentProcessors: resolve stack logical name using precedence
ComponentProcessors->>Workspace: derive Terraform workspace from resolved logical name
ComponentProcessors-->>CLI: return processed stack info
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25–30 minutes
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
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. Comment |
📝 WalkthroughWalkthroughThis PR introduces per-stack manifest-level name overrides. It adds a Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–25 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
website/blog/2025-12-03-stack-manifest-name-override.mdx (1)
135-143: Minor wording suggestion.The static analysis flagged word repetition on line 143 ("needs" used twice). Consider rewording for variety.
-Add a `name` field to any stack manifest that needs an explicit name. This feature is fully backward compatible - stacks without a `name` field continue to use `name_template`, `name_pattern`, or the filename as before. +Add a `name` field to any stack manifest requiring an explicit override. This feature is fully backward compatible—stacks without a `name` field continue to use `name_template`, `name_pattern`, or the filename as before.internal/exec/stack_manifest_name_test.go (2)
15-148: Extract repeated test setup to reduce duplication.All three test functions have identical setup code (changing directory, initializing config). Consider extracting this into a helper function and defining the test directory as a constant.
Apply this pattern:
+const testFixtureDir = "../../tests/fixtures/scenarios/stack-manifest-name" + +// setupTest initializes the test environment and returns the atmos config. +func setupTest(t *testing.T) schema.AtmosConfiguration { + t.Helper() + t.Chdir(testFixtureDir) + + configAndStacksInfo := schema.ConfigAndStacksInfo{} + atmosConfig, err := cfg.InitCliConfig(configAndStacksInfo, true) + require.NoError(t, err) + + return atmosConfig +} + func TestStackManifestNameInStacksMap(t *testing.T) { - // Change to the test fixture directory. - testDir := "../../tests/fixtures/scenarios/stack-manifest-name" - t.Chdir(testDir) - - // Initialize the CLI config. - configAndStacksInfo := schema.ConfigAndStacksInfo{} - atmosConfig, err := cfg.InitCliConfig(configAndStacksInfo, true) - require.NoError(t, err) + atmosConfig := setupTest(t) // Call FindStacksMap to get the processed stacks. stacksMap, _, err := FindStacksMap(&atmosConfig, false)
59-98: Consider adding error case coverage.The tests validate happy paths well, but consider adding test cases for error scenarios to improve coverage:
- Invalid or empty name values in manifests
- Missing fixture files
- Malformed stack configurations
This would help catch edge cases and improve overall test reliability.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (15)
CLAUDE.md(1 hunks)internal/exec/describe_stacks.go(7 hunks)internal/exec/stack_manifest_name_test.go(1 hunks)internal/exec/stack_processor_process_stacks.go(2 hunks)internal/exec/stack_utils.go(1 hunks)pkg/config/const.go(1 hunks)pkg/datafetcher/schema/stacks/stack-config/1.0.json(2 hunks)pkg/schema/schema.go(1 hunks)tests/fixtures/scenarios/stack-manifest-name/atmos.yaml(1 hunks)tests/fixtures/scenarios/stack-manifest-name/components/terraform/mock/main.tf(1 hunks)tests/fixtures/scenarios/stack-manifest-name/stacks/catalog/base.yaml(1 hunks)tests/fixtures/scenarios/stack-manifest-name/stacks/legacy-prod.yaml(1 hunks)tests/fixtures/scenarios/stack-manifest-name/stacks/no-name-prod.yaml(1 hunks)website/blog/2025-12-03-stack-manifest-name-override.mdx(1 hunks)website/docs/core-concepts/stacks/stacks.mdx(2 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
**/*.go
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.go: Use functional options pattern to avoid functions with many parameters. Define Option functions that modify a Config struct and pass variadic options to New functions.
Use context.Context for cancellation signals, deadlines/timeouts, and request-scoped values (trace IDs). Context should be first parameter in functions that accept it. DO NOT use context for configuration, dependencies, or avoiding proper function parameters.
All comments must end with periods. This is enforced by the godot linter.
NEVER delete existing comments without a very strong reason. Preserve helpful comments, update them to match code changes, refactor for clarity, and add context when modifying code. Only remove factually incorrect, duplicated, or outdated comments.
Organize imports in three groups separated by blank lines (Go stdlib, 3rd-party excluding cloudposse/atmos, Atmos packages), sorted alphabetically. Maintain aliases: cfg, log, u, errUtils.
Add defer perf.Track(atmosConfig, "pkg.FuncName")() + blank line to all public functions. Use nil if no atmosConfig parameter.
All errors MUST be wrapped using static errors defined in errors/errors.go. Use errors.Join for combining multiple errors, fmt.Errorf with %w for adding string context, error builder for complex errors, and errors.Is() for error checking. NEVER use dynamic errors directly.
Use go.uber.org/mock/mockgen with //go:generate directives for mock generation. Never create manual mocks.
Use viper.BindEnv with ATMOS_ prefix for environment variables.
Use colors from pkg/ui/theme/colors.go for theme consistency.
Ensure Linux/macOS/Windows compatibility. Use SDKs over binaries. Use filepath.Join(), not hardcoded path separators.
Small focused files (<600 lines). One cmd/impl per file. Co-locate tests. Never use //revive:disable:file-length-limit.
**/*.go: Use Viper for managing configuration, environment variables, and flags in CLI commands
Use interfaces for external dependencies to facilitate mocking and consider us...
Files:
pkg/schema/schema.gopkg/config/const.gointernal/exec/stack_processor_process_stacks.gointernal/exec/stack_utils.gointernal/exec/stack_manifest_name_test.gointernal/exec/describe_stacks.go
website/blog/**/*.mdx
📄 CodeRabbit inference engine (CLAUDE.md)
PRs labeled minor/major MUST include blog post at website/blog/YYYY-MM-DD-feature-name.mdx with YAML front matter, after intro, tags (feature/enhancement/bugfix/contributors), and author (committer's GitHub username).
Files:
website/blog/2025-12-03-stack-manifest-name-override.mdx
website/**
📄 CodeRabbit inference engine (.cursor/rules/atmos-rules.mdc)
website/**: Update website documentation in thewebsite/directory when adding new features, ensure consistency between CLI help text and website documentation, and follow the website's documentation structure and style
Keep website code in thewebsite/directory, follow the existing website architecture and style, and test website changes locally before committing
Keep CLI documentation and website documentation in sync and document new features on the website with examples and use cases
Files:
website/blog/2025-12-03-stack-manifest-name-override.mdxwebsite/docs/core-concepts/stacks/stacks.mdx
**/*_test.go
📄 CodeRabbit inference engine (CLAUDE.md)
**/*_test.go: Prefer unit tests with mocks over integration tests. Use interfaces + dependency injection for testability. Generate mocks with go.uber.org/mock/mockgen. Use table-driven tests for comprehensive coverage. Target >80% code coverage.
Test behavior, not implementation. Never test stub functions. Avoid tautological tests. Make code testable with DI to avoid os.Exit and external systems. Use assert.ErrorIs(err, ErrSentinel) for stdlib/our errors.
**/*_test.go: Every new feature must include comprehensive unit tests targeting >80% code coverage for all packages
Use table-driven tests for testing multiple scenarios in Go
Include integration tests for command flows and test CLI end-to-end when possible with test fixtures
Files:
internal/exec/stack_manifest_name_test.go
pkg/datafetcher/schema/**/*.json
📄 CodeRabbit inference engine (CLAUDE.md)
Update all schemas in pkg/datafetcher/schema/ when adding config options.
Files:
pkg/datafetcher/schema/stacks/stack-config/1.0.json
🧠 Learnings (34)
📓 Common learnings
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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: haitham911
Repo: cloudposse/atmos PR: 731
File: internal/exec/validate_stacks.go:93-98
Timestamp: 2024-10-20T00:41:57.135Z
Learning: When downloading schema files in `internal/exec/validate_stacks.go`, use a consistent temporary file name to overwrite the file each time and avoid creating multiple temporary files.
📚 Learning: 2024-10-20T00:41:57.135Z
Learnt from: haitham911
Repo: cloudposse/atmos PR: 731
File: internal/exec/validate_stacks.go:93-98
Timestamp: 2024-10-20T00:41:57.135Z
Learning: When downloading schema files in `internal/exec/validate_stacks.go`, use a consistent temporary file name to overwrite the file each time and avoid creating multiple temporary files.
Applied to files:
pkg/schema/schema.gointernal/exec/stack_utils.gointernal/exec/stack_manifest_name_test.gointernal/exec/describe_stacks.go
📚 Learning: 2025-09-29T02:20:11.636Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 1540
File: internal/exec/validate_component.go:117-118
Timestamp: 2025-09-29T02:20:11.636Z
Learning: The ValidateComponent function in internal/exec/validate_component.go had its componentSection parameter type refined from `any` to `map[string]any` without adding new parameters. This is a type safety improvement, not a signature change requiring call site updates.
Applied to files:
pkg/config/const.go
📚 Learning: 2024-11-13T21:37:07.852Z
Learnt from: Cerebrovinny
Repo: cloudposse/atmos PR: 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/stack_processor_process_stacks.gointernal/exec/stack_utils.gointernal/exec/stack_manifest_name_test.gointernal/exec/describe_stacks.go
📚 Learning: 2024-11-19T23:00:45.899Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 795
File: internal/exec/stack_processor_utils.go:378-386
Timestamp: 2024-11-19T23:00:45.899Z
Learning: In the `ProcessYAMLConfigFile` function within `internal/exec/stack_processor_utils.go`, directory traversal in stack imports is acceptable and should not be restricted.
Applied to files:
internal/exec/stack_processor_process_stacks.gointernal/exec/stack_manifest_name_test.go
📚 Learning: 2024-12-07T16:16:13.038Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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/stack_processor_process_stacks.gointernal/exec/stack_utils.gotests/fixtures/scenarios/stack-manifest-name/atmos.yamlinternal/exec/stack_manifest_name_test.gointernal/exec/describe_stacks.go
📚 Learning: 2025-10-13T18:13:54.020Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 1622
File: pkg/perf/perf.go:140-184
Timestamp: 2025-10-13T18:13:54.020Z
Learning: In pkg/perf/perf.go, the `trackWithSimpleStack` function intentionally skips ownership checks at call stack depth > 1 to avoid expensive `getGoroutineID()` calls on every nested function. This is a performance optimization for the common single-goroutine execution case (most Atmos commands), accepting the rare edge case of potential metric corruption if multi-goroutine execution occurs at depth > 1. The ~19× performance improvement justifies this trade-off.
Applied to files:
internal/exec/stack_processor_process_stacks.go
📚 Learning: 2024-12-08T14:26:16.972Z
Learnt from: pkbhowmick
Repo: cloudposse/atmos PR: 828
File: pkg/schema/schema.go:98-100
Timestamp: 2024-12-08T14:26:16.972Z
Learning: The `ListConfig` columns array in the `Components` struct can be empty.
Applied to files:
internal/exec/stack_processor_process_stacks.go
📚 Learning: 2024-12-07T16:19:01.683Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 825
File: internal/exec/terraform.go:30-30
Timestamp: 2024-12-07T16:19:01.683Z
Learning: In `internal/exec/terraform.go`, skipping stack validation when help flags are present is not necessary.
Applied to files:
internal/exec/stack_utils.gointernal/exec/stack_manifest_name_test.go
📚 Learning: 2024-11-02T15:35:09.958Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 759
File: internal/exec/terraform.go:366-368
Timestamp: 2024-11-02T15:35:09.958Z
Learning: In `internal/exec/terraform.go`, the workspace cleaning code under both the general execution path and within the `case "init":` block is intentionally duplicated because the code execution paths are different. The `.terraform/environment` file should be deleted before executing `terraform init` in both scenarios to ensure a clean state.
Applied to files:
internal/exec/stack_utils.go
📚 Learning: 2024-11-12T03:16:02.910Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 775
File: internal/exec/template_funcs_component.go:157-159
Timestamp: 2024-11-12T03:16:02.910Z
Learning: In the Go code for `componentFunc` in `internal/exec/template_funcs_component.go`, the function `cleanTerraformWorkspace` does not return errors, and it's acceptable if the file does not exist. Therefore, error handling for `cleanTerraformWorkspace` is not needed.
Applied to files:
internal/exec/stack_utils.go
📚 Learning: 2024-12-12T15:17:45.245Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 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:
internal/exec/stack_utils.go
📚 Learning: 2024-12-03T04:01:16.446Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 810
File: website/docs/core-concepts/stacks/yaml-functions/terraform.output.mdx:0-0
Timestamp: 2024-12-03T04:01:16.446Z
Learning: In the `terraform.output.mdx` documentation file (`website/docs/core-concepts/stacks/yaml-functions/terraform.output.mdx`), the cache invalidation and cache scope behavior for the `!terraform.output` function are already described.
Applied to files:
website/blog/2025-12-03-stack-manifest-name-override.mdx
📚 Learning: 2024-11-25T17:17:15.703Z
Learnt from: RoseSecurity
Repo: cloudposse/atmos PR: 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/stack-manifest-name/atmos.yaml
📚 Learning: 2025-09-24T20:45:40.401Z
Learnt from: Benbentwo
Repo: cloudposse/atmos PR: 1475
File: tests/fixtures/scenarios/atmos-auth/stacks/deploy/nonprod.yaml:3-4
Timestamp: 2025-09-24T20:45:40.401Z
Learning: In Atmos stack files, the correct syntax for importing other stack files is `import:` (singular), not `imports:` (plural). All stack files in the Atmos codebase consistently use `import:` followed by a list of paths to import.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yamlwebsite/docs/core-concepts/stacks/stacks.mdxpkg/datafetcher/schema/stacks/stack-config/1.0.json
📚 Learning: 2025-09-10T21:17:55.273Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1466
File: toolchain/http_client_test.go:3-10
Timestamp: 2025-09-10T21:17:55.273Z
Learning: In the cloudposse/atmos repository, imports should never be changed as per samtholiya's coding guidelines.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-03-18T12:26:25.329Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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/stack-manifest-name/atmos.yaml
📚 Learning: 2025-01-25T03:51:57.689Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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/stack-manifest-name/atmos.yaml
📚 Learning: 2025-01-25T15:21:40.413Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 808
File: examples/demo-atmos-cli-imports/atmos.yaml:8-8
Timestamp: 2025-01-25T15:21:40.413Z
Learning: In Atmos, when a directory is specified for configuration loading (e.g., in the `import` section of atmos.yaml), all files within that directory should be treated as Atmos configurations. Do not suggest restricting file extensions in directory-based glob patterns.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-09-08T01:25:44.958Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/docs/cli/commands/toolchain/usage.mdx:117-121
Timestamp: 2025-09-08T01:25:44.958Z
Learning: The atmos toolchain has been updated to follow XDG Base Directory Specification with helper functions GetXDGCacheDir() and GetXDGTempCacheDir() in toolchain/xdg_cache.go, using XDG_CACHE_HOME when set and falling back to ~/.cache/atmos-toolchain, making it consistent with atmos core's XDG compliance.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-09-13T16:39:20.007Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1466
File: cmd/markdown/atmos_toolchain_aliases.md:2-4
Timestamp: 2025-09-13T16:39:20.007Z
Learning: In the cloudposse/atmos repository, CLI documentation files in cmd/markdown/ follow a specific format that uses " $ atmos command" (with leading space and dollar sign prompt) in code blocks. This is the established project convention and should not be changed to comply with standard markdownlint rules MD040 and MD014.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-11-01T20:24:29.557Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1714
File: NOTICE:0-0
Timestamp: 2025-11-01T20:24:29.557Z
Learning: In the cloudposse/atmos repository, the NOTICE file is programmatically generated and should not be manually edited. Issues with dependency license URLs in NOTICE will be resolved when upstream package metadata is corrected.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-11-24T17:35:20.297Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T17:35:20.297Z
Learning: Applies to website/blog/**/*.mdx : PRs labeled minor/major MUST include blog post at website/blog/YYYY-MM-DD-feature-name.mdx with YAML front matter, <!--truncate--> after intro, tags (feature/enhancement/bugfix/contributors), and author (committer's GitHub username).
Applied to files:
CLAUDE.md
📚 Learning: 2025-11-29T17:35:01.177Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1819
File: website/blog/2025-10-13-introducing-atmos-auth.md:5-6
Timestamp: 2025-11-29T17:35:01.177Z
Learning: In the Atmos blog (website/blog/), blog post authors should be set to the actual content author (the person who wrote the feature/content), not generic organization names like "cloudposse" or "atmos". If the actual author differs from the PR opener, use the actual author. Authors must exist in website/blog/authors.yml.
Applied to files:
CLAUDE.md
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to website/** : Update website documentation in the `website/` directory when adding new features, ensure consistency between CLI help text and website documentation, and follow the website's documentation structure and style
Applied to files:
CLAUDE.md
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to CHANGELOG.md : Follow semantic versioning, update CHANGELOG.md with each release, and create GitHub releases with detailed release notes
Applied to files:
CLAUDE.md
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to website/** : Keep CLI documentation and website documentation in sync and document new features on the website with examples and use cases
Applied to files:
CLAUDE.md
📚 Learning: 2024-12-01T00:33:20.298Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 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/stack-manifest-name/components/terraform/mock/main.tftests/fixtures/scenarios/stack-manifest-name/stacks/no-name-prod.yamlinternal/exec/stack_manifest_name_test.go
📚 Learning: 2025-11-24T17:35:20.297Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T17:35:20.297Z
Learning: Applies to internal/exec/template_funcs.go : New configs support Go templating with FuncMap() from internal/exec/template_funcs.go. Implement template functions in internal/exec/template_funcs.go, register them, add tests, and update documentation.
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to **/*_test.go : Include integration tests for command flows and test CLI end-to-end when possible with test fixtures
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2024-10-20T00:57:53.500Z
Learnt from: haitham911
Repo: cloudposse/atmos PR: 731
File: internal/exec/validate_stacks.go:0-0
Timestamp: 2024-10-20T00:57:53.500Z
Learning: In `internal/exec/validate_stacks.go`, when downloading the Atmos JSON Schema file to the temp directory, the temporary file is overwritten each time, so explicit removal is not necessary.
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2024-10-31T19:23:45.538Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 727
File: internal/exec/terraform.go:65-66
Timestamp: 2024-10-31T19:23:45.538Z
Learning: The variable `shouldCheckStack` in `ExecuteTerraform` controls whether validation is performed.
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2025-11-24T17:35:20.297Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T17:35:20.297Z
Learning: Applies to pkg/datafetcher/schema/**/*.json : Update all schemas in pkg/datafetcher/schema/ when adding config options.
Applied to files:
pkg/datafetcher/schema/stacks/stack-config/1.0.json
📚 Learning: 2025-06-23T02:14:30.937Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 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/describe_stacks.go
🪛 LanguageTool
website/blog/2025-12-03-stack-manifest-name-override.mdx
[typographical] ~24-~24: To join two clauses or introduce examples, consider using an em dash.
Context: ...nt}-{environment}-{stage}` - Default - The basename of the stack file (zero-con...
(DASH_RULE)
[typographical] ~57-~57: To join two clauses or introduce examples, consider using an em dash.
Context: ... in this order: 1. name (highest) - Explicit name from stack manifest 2. **`...
(DASH_RULE)
[typographical] ~59-~59: To join two clauses or introduce examples, consider using an em dash.
Context: ... from atmos.yaml 3. name_pattern - Token pattern from atmos.yaml 4. **Def...
(DASH_RULE)
[typographical] ~60-~60: To join two clauses or introduce examples, consider using an em dash.
Context: ...pattern from atmos.yaml 4. Default - Basename of the stack file This means y...
(DASH_RULE)
[style] ~143-~143: 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: ...name field to any stack manifest that needs an explicit name. This feature is fully...
(EN_REPEATEDWORDS_NEED)
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Acceptance Tests (windows)
- GitHub Check: Summary
🔇 Additional comments (27)
tests/fixtures/scenarios/stack-manifest-name/components/terraform/mock/main.tf (1)
1-17: LGTM!Clean test fixture with sensible defaults for exercising the stack manifest name feature.
tests/fixtures/scenarios/stack-manifest-name/stacks/catalog/base.yaml (1)
1-10: LGTM!Well-structured base catalog that provides shared configuration for the test scenario.
tests/fixtures/scenarios/stack-manifest-name/stacks/no-name-prod.yaml (1)
1-13: LGTM!Excellent test fixture for validating the fallback behavior when no explicit
nameis provided. The comment clearly documents the intent.pkg/schema/schema.go (1)
625-625: LGTM!Clean addition of the
StackManifestNamefield with clear documentation explaining its role in the naming precedence hierarchy.internal/exec/stack_utils.go (1)
29-45: LGTM!The precedence logic is cleanly implemented. The manifest name takes priority as intended, with appropriate fallbacks to
name_template,name_pattern, and finally the filename. The comment clearly documents the precedence order.tests/fixtures/scenarios/stack-manifest-name/atmos.yaml (1)
1-12: LGTM!Standard test configuration that properly sets up the environment for validating the stack manifest name feature.
website/docs/core-concepts/stacks/stacks.mdx (1)
105-186: LGTM!Excellent documentation that clearly explains the new
nameoverride feature, its precedence, and provides a practical example. The use case justification helps users understand when to apply this feature.pkg/config/const.go (1)
65-65: LGTM!Clean addition of the
NameSectionNameconstant, consistently named and appropriately placed alongside other section constants.tests/fixtures/scenarios/stack-manifest-name/stacks/legacy-prod.yaml (1)
1-15: LGTM!Clean fixture that demonstrates the new
namefield override. The structure is correct and the comment clearly indicates the purpose.internal/exec/stack_processor_process_stacks.go (2)
51-57: LGTM!The extraction logic correctly reads the optional
namefield with proper type assertion and follows the existing pattern used for other global sections.
522-525: LGTM!Correctly injects the stack manifest name into the result map only when set, maintaining backward compatibility.
website/blog/2025-12-03-stack-manifest-name-override.mdx (2)
1-9: LGTM!Front matter is properly structured with required fields. The
featuretag andostermanauthor align with the PR guidelines.
53-62: Documentation aligns with implementation.The precedence order documented here matches the code implementation across
describe_stacks.goandstack_utils.go. This consistency is important.pkg/datafetcher/schema/stacks/stack-config/1.0.json (2)
7-10: LGTM!The
nameproperty is correctly defined with proper type and a clear description that explains the precedence behavior.
111-116: LGTM!Adding
nameto theanyOfalternatives allows a minimal manifest with just a name override to be valid. This follows the existing pattern for other optional top-level fields.CLAUDE.md (2)
420-421: LGTM!Good addition. Requiring explicit reads of
tags.ymlandauthors.ymlprevents invalid metadata in blog posts.
436-438: LGTM!The expanded tag taxonomy and the
coretag for internal changes provide better categorization options.internal/exec/describe_stacks.go (8)
149-149: LGTM!Variable declaration follows the existing pattern of declaring section variables at function scope.
157-163: LGTM!Correctly extracts the stack-level name override at the start of stack processing. The pattern matches other extraction logic in this file.
264-290: LGTM!The
StackManifestNamefield is correctly populated inConfigAndStacksInfofor Terraform components. This ensures the manifest name flows through to workspace derivation.
304-322: Precedence logic is correct.The stack name resolution follows the documented order: manifest name > name_template > name_pattern > filename. The explicit else clause for filename fallback is a good addition for clarity.
Based on retrieved learnings, the duplication across component types is intentional.
512-538: LGTM!
StackManifestNameis consistently populated for Helmfile components, matching the Terraform implementation.
552-570: LGTM!Helmfile precedence logic is consistent with Terraform. The duplication is acceptable per project conventions.
737-763: LGTM!
StackManifestNameis consistently populated for Packer components, completing the coverage across all component types.
777-795: LGTM!Packer precedence logic completes the consistent implementation across all component types. Well done maintaining parity.
internal/exec/stack_manifest_name_test.go (2)
3-11: Import organization looks solid.The three-group structure with proper aliases follows the guidelines perfectly.
130-147: Deep nesting is explicit but verbose.The nested type assertions provide good error messages at each level, which is helpful for debugging. Just be aware that this makes the test somewhat brittle to structure changes. The current approach is fine for verifying this specific behavior.
osterman
force-pushed
the
osterman/stack-manifest-name
branch
from
6241bf4 to
d53cf4b
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
internal/exec/stack_processor_process_stacks.go (1)
51-57: Stack manifestnameextraction/propagation looks good, with one optional tightening.The new logic cleanly:
- Reads a string
namefrom the raw config without affecting existing processing.- Adds it back into the processed
resultmap so downstream consumers can respect the manifest override.One thing you might consider aligning with other top-level sections: if
config["name"]is present but not a string, you currently ignore it. Other sections (e.g.,vars,terraform) return a typed error on mismatch. If you want consistent validation, treating a non-stringnameas an error instead of silently dropping it could make misconfigurations more obvious.Also applies to: 522-525
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (15)
CLAUDE.md(1 hunks)internal/exec/describe_stacks.go(7 hunks)internal/exec/stack_manifest_name_test.go(1 hunks)internal/exec/stack_processor_process_stacks.go(2 hunks)internal/exec/stack_utils.go(1 hunks)pkg/config/const.go(1 hunks)pkg/datafetcher/schema/stacks/stack-config/1.0.json(2 hunks)pkg/schema/schema.go(1 hunks)tests/fixtures/scenarios/stack-manifest-name/atmos.yaml(1 hunks)tests/fixtures/scenarios/stack-manifest-name/components/terraform/mock/main.tf(1 hunks)tests/fixtures/scenarios/stack-manifest-name/stacks/catalog/base.yaml(1 hunks)tests/fixtures/scenarios/stack-manifest-name/stacks/legacy-prod.yaml(1 hunks)tests/fixtures/scenarios/stack-manifest-name/stacks/no-name-prod.yaml(1 hunks)website/blog/2025-12-03-stack-manifest-name-override.mdx(1 hunks)website/docs/learn/stacks/stacks.mdx(2 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
**/*.go
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.go: Use functional options pattern to avoid functions with many parameters. Define Option functions that modify a Config struct and pass variadic options to New functions.
Use context.Context for cancellation signals, deadlines/timeouts, and request-scoped values (trace IDs). Context should be first parameter in functions that accept it. DO NOT use context for configuration, dependencies, or avoiding proper function parameters.
All comments must end with periods. This is enforced by the godot linter.
NEVER delete existing comments without a very strong reason. Preserve helpful comments, update them to match code changes, refactor for clarity, and add context when modifying code. Only remove factually incorrect, duplicated, or outdated comments.
Organize imports in three groups separated by blank lines (Go stdlib, 3rd-party excluding cloudposse/atmos, Atmos packages), sorted alphabetically. Maintain aliases: cfg, log, u, errUtils.
Add defer perf.Track(atmosConfig, "pkg.FuncName")() + blank line to all public functions. Use nil if no atmosConfig parameter.
All errors MUST be wrapped using static errors defined in errors/errors.go. Use errors.Join for combining multiple errors, fmt.Errorf with %w for adding string context, error builder for complex errors, and errors.Is() for error checking. NEVER use dynamic errors directly.
Use go.uber.org/mock/mockgen with //go:generate directives for mock generation. Never create manual mocks.
Use viper.BindEnv with ATMOS_ prefix for environment variables.
Use colors from pkg/ui/theme/colors.go for theme consistency.
Ensure Linux/macOS/Windows compatibility. Use SDKs over binaries. Use filepath.Join(), not hardcoded path separators.
Small focused files (<600 lines). One cmd/impl per file. Co-locate tests. Never use //revive:disable:file-length-limit.
**/*.go: Use Viper for managing configuration, environment variables, and flags in CLI commands
Use interfaces for external dependencies to facilitate mocking and consider us...
Files:
pkg/config/const.gopkg/schema/schema.gointernal/exec/stack_utils.gointernal/exec/describe_stacks.gointernal/exec/stack_processor_process_stacks.gointernal/exec/stack_manifest_name_test.go
website/blog/**/*.mdx
📄 CodeRabbit inference engine (CLAUDE.md)
PRs labeled minor/major MUST include blog post at website/blog/YYYY-MM-DD-feature-name.mdx with YAML front matter, after intro, tags (feature/enhancement/bugfix/contributors), and author (committer's GitHub username).
Files:
website/blog/2025-12-03-stack-manifest-name-override.mdx
website/**
📄 CodeRabbit inference engine (.cursor/rules/atmos-rules.mdc)
website/**: Update website documentation in thewebsite/directory when adding new features, ensure consistency between CLI help text and website documentation, and follow the website's documentation structure and style
Keep website code in thewebsite/directory, follow the existing website architecture and style, and test website changes locally before committing
Keep CLI documentation and website documentation in sync and document new features on the website with examples and use cases
Files:
website/blog/2025-12-03-stack-manifest-name-override.mdxwebsite/docs/learn/stacks/stacks.mdx
**/*_test.go
📄 CodeRabbit inference engine (CLAUDE.md)
**/*_test.go: Prefer unit tests with mocks over integration tests. Use interfaces + dependency injection for testability. Generate mocks with go.uber.org/mock/mockgen. Use table-driven tests for comprehensive coverage. Target >80% code coverage.
Test behavior, not implementation. Never test stub functions. Avoid tautological tests. Make code testable with DI to avoid os.Exit and external systems. Use assert.ErrorIs(err, ErrSentinel) for stdlib/our errors.
**/*_test.go: Every new feature must include comprehensive unit tests targeting >80% code coverage for all packages
Use table-driven tests for testing multiple scenarios in Go
Include integration tests for command flows and test CLI end-to-end when possible with test fixtures
Files:
internal/exec/stack_manifest_name_test.go
pkg/datafetcher/schema/**/*.json
📄 CodeRabbit inference engine (CLAUDE.md)
Update all schemas in pkg/datafetcher/schema/ when adding config options.
Files:
pkg/datafetcher/schema/stacks/stack-config/1.0.json
🧠 Learnings (32)
📓 Common learnings
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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.
📚 Learning: 2025-09-29T02:20:11.636Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 1540
File: internal/exec/validate_component.go:117-118
Timestamp: 2025-09-29T02:20:11.636Z
Learning: The ValidateComponent function in internal/exec/validate_component.go had its componentSection parameter type refined from `any` to `map[string]any` without adding new parameters. This is a type safety improvement, not a signature change requiring call site updates.
Applied to files:
pkg/config/const.go
📚 Learning: 2025-11-24T17:35:20.297Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T17:35:20.297Z
Learning: Applies to website/blog/**/*.mdx : PRs labeled minor/major MUST include blog post at website/blog/YYYY-MM-DD-feature-name.mdx with YAML front matter, <!--truncate--> after intro, tags (feature/enhancement/bugfix/contributors), and author (committer's GitHub username).
Applied to files:
CLAUDE.md
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to website/** : Update website documentation in the `website/` directory when adding new features, ensure consistency between CLI help text and website documentation, and follow the website's documentation structure and style
Applied to files:
CLAUDE.md
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to website/** : Keep CLI documentation and website documentation in sync and document new features on the website with examples and use cases
Applied to files:
CLAUDE.md
📚 Learning: 2025-11-29T17:35:01.177Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1819
File: website/blog/2025-10-13-introducing-atmos-auth.md:5-6
Timestamp: 2025-11-29T17:35:01.177Z
Learning: In the Atmos blog (website/blog/), blog post authors should be set to the actual content author (the person who wrote the feature/content), not generic organization names like "cloudposse" or "atmos". If the actual author differs from the PR opener, use the actual author. Authors must exist in website/blog/authors.yml.
Applied to files:
CLAUDE.md
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to CHANGELOG.md : Follow semantic versioning, update CHANGELOG.md with each release, and create GitHub releases with detailed release notes
Applied to files:
CLAUDE.md
📚 Learning: 2024-10-20T00:41:57.135Z
Learnt from: haitham911
Repo: cloudposse/atmos PR: 731
File: internal/exec/validate_stacks.go:93-98
Timestamp: 2024-10-20T00:41:57.135Z
Learning: When downloading schema files in `internal/exec/validate_stacks.go`, use a consistent temporary file name to overwrite the file each time and avoid creating multiple temporary files.
Applied to files:
pkg/schema/schema.gointernal/exec/describe_stacks.gointernal/exec/stack_manifest_name_test.go
📚 Learning: 2024-11-13T21:37:07.852Z
Learnt from: Cerebrovinny
Repo: cloudposse/atmos PR: 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/stack_utils.gointernal/exec/describe_stacks.gointernal/exec/stack_processor_process_stacks.gointernal/exec/stack_manifest_name_test.go
📚 Learning: 2024-11-02T15:35:09.958Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 759
File: internal/exec/terraform.go:366-368
Timestamp: 2024-11-02T15:35:09.958Z
Learning: In `internal/exec/terraform.go`, the workspace cleaning code under both the general execution path and within the `case "init":` block is intentionally duplicated because the code execution paths are different. The `.terraform/environment` file should be deleted before executing `terraform init` in both scenarios to ensure a clean state.
Applied to files:
internal/exec/stack_utils.go
📚 Learning: 2024-11-12T03:16:02.910Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 775
File: internal/exec/template_funcs_component.go:157-159
Timestamp: 2024-11-12T03:16:02.910Z
Learning: In the Go code for `componentFunc` in `internal/exec/template_funcs_component.go`, the function `cleanTerraformWorkspace` does not return errors, and it's acceptable if the file does not exist. Therefore, error handling for `cleanTerraformWorkspace` is not needed.
Applied to files:
internal/exec/stack_utils.go
📚 Learning: 2024-12-12T15:17:45.245Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 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:
internal/exec/stack_utils.go
📚 Learning: 2024-12-07T16:16:13.038Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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/stack_utils.gointernal/exec/describe_stacks.gointernal/exec/stack_processor_process_stacks.gointernal/exec/stack_manifest_name_test.go
📚 Learning: 2024-12-01T00:33:20.298Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 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/stack-manifest-name/stacks/no-name-prod.yamltests/fixtures/scenarios/stack-manifest-name/atmos.yamlinternal/exec/stack_manifest_name_test.gotests/fixtures/scenarios/stack-manifest-name/components/terraform/mock/main.tf
📚 Learning: 2025-06-23T02:14:30.937Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 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/describe_stacks.go
📚 Learning: 2025-09-24T20:45:40.401Z
Learnt from: Benbentwo
Repo: cloudposse/atmos PR: 1475
File: tests/fixtures/scenarios/atmos-auth/stacks/deploy/nonprod.yaml:3-4
Timestamp: 2025-09-24T20:45:40.401Z
Learning: In Atmos stack files, the correct syntax for importing other stack files is `import:` (singular), not `imports:` (plural). All stack files in the Atmos codebase consistently use `import:` followed by a list of paths to import.
Applied to files:
website/docs/learn/stacks/stacks.mdxtests/fixtures/scenarios/stack-manifest-name/atmos.yamlpkg/datafetcher/schema/stacks/stack-config/1.0.json
📚 Learning: 2024-11-25T17:17:15.703Z
Learnt from: RoseSecurity
Repo: cloudposse/atmos PR: 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/stack-manifest-name/atmos.yaml
📚 Learning: 2025-03-18T12:26:25.329Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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/stack-manifest-name/atmos.yaml
📚 Learning: 2025-09-10T21:17:55.273Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1466
File: toolchain/http_client_test.go:3-10
Timestamp: 2025-09-10T21:17:55.273Z
Learning: In the cloudposse/atmos repository, imports should never be changed as per samtholiya's coding guidelines.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-01-25T03:51:57.689Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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/stack-manifest-name/atmos.yaml
📚 Learning: 2025-01-08T19:01:32.938Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 899
File: examples/tests/test-vendor/test-components/main.tf:1-7
Timestamp: 2025-01-08T19:01:32.938Z
Learning: In the examples/tests directory of the atmos project, code examples are intentionally kept minimal and simple to facilitate understanding. Avoid suggesting additional complexity or validations that might make the examples harder to follow.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-11-01T20:24:29.557Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1714
File: NOTICE:0-0
Timestamp: 2025-11-01T20:24:29.557Z
Learning: In the cloudposse/atmos repository, the NOTICE file is programmatically generated and should not be manually edited. Issues with dependency license URLs in NOTICE will be resolved when upstream package metadata is corrected.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-02-14T23:12:38.030Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 1061
File: tests/snapshots/TestCLICommands_atmos_vendor_pull_ssh.stderr.golden:8-8
Timestamp: 2025-02-14T23:12:38.030Z
Learning: Test snapshots in the Atmos project, particularly for dry run scenarios, may be updated during the development process, and temporary inconsistencies in their content should not be flagged as issues.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-09-08T01:25:44.958Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/docs/cli/commands/toolchain/usage.mdx:117-121
Timestamp: 2025-09-08T01:25:44.958Z
Learning: The atmos toolchain has been updated to follow XDG Base Directory Specification with helper functions GetXDGCacheDir() and GetXDGTempCacheDir() in toolchain/xdg_cache.go, using XDG_CACHE_HOME when set and falling back to ~/.cache/atmos-toolchain, making it consistent with atmos core's XDG compliance.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2024-11-19T23:00:45.899Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 795
File: internal/exec/stack_processor_utils.go:378-386
Timestamp: 2024-11-19T23:00:45.899Z
Learning: In the `ProcessYAMLConfigFile` function within `internal/exec/stack_processor_utils.go`, directory traversal in stack imports is acceptable and should not be restricted.
Applied to files:
internal/exec/stack_processor_process_stacks.go
📚 Learning: 2025-10-13T18:13:54.020Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 1622
File: pkg/perf/perf.go:140-184
Timestamp: 2025-10-13T18:13:54.020Z
Learning: In pkg/perf/perf.go, the `trackWithSimpleStack` function intentionally skips ownership checks at call stack depth > 1 to avoid expensive `getGoroutineID()` calls on every nested function. This is a performance optimization for the common single-goroutine execution case (most Atmos commands), accepting the rare edge case of potential metric corruption if multi-goroutine execution occurs at depth > 1. The ~19× performance improvement justifies this trade-off.
Applied to files:
internal/exec/stack_processor_process_stacks.go
📚 Learning: 2024-12-08T14:26:16.972Z
Learnt from: pkbhowmick
Repo: cloudposse/atmos PR: 828
File: pkg/schema/schema.go:98-100
Timestamp: 2024-12-08T14:26:16.972Z
Learning: The `ListConfig` columns array in the `Components` struct can be empty.
Applied to files:
internal/exec/stack_processor_process_stacks.go
📚 Learning: 2025-11-24T17:35:20.297Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T17:35:20.297Z
Learning: Applies to internal/exec/template_funcs.go : New configs support Go templating with FuncMap() from internal/exec/template_funcs.go. Implement template functions in internal/exec/template_funcs.go, register them, add tests, and update documentation.
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to **/*_test.go : Include integration tests for command flows and test CLI end-to-end when possible with test fixtures
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2024-12-07T16:19:01.683Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 825
File: internal/exec/terraform.go:30-30
Timestamp: 2024-12-07T16:19:01.683Z
Learning: In `internal/exec/terraform.go`, skipping stack validation when help flags are present is not necessary.
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2024-10-20T00:57:53.500Z
Learnt from: haitham911
Repo: cloudposse/atmos PR: 731
File: internal/exec/validate_stacks.go:0-0
Timestamp: 2024-10-20T00:57:53.500Z
Learning: In `internal/exec/validate_stacks.go`, when downloading the Atmos JSON Schema file to the temp directory, the temporary file is overwritten each time, so explicit removal is not necessary.
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2024-10-31T19:23:45.538Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 727
File: internal/exec/terraform.go:65-66
Timestamp: 2024-10-31T19:23:45.538Z
Learning: The variable `shouldCheckStack` in `ExecuteTerraform` controls whether validation is performed.
Applied to files:
internal/exec/stack_manifest_name_test.go
🧬 Code graph analysis (4)
internal/exec/stack_utils.go (1)
pkg/schema/schema.go (1)
Stacks(439-445)
internal/exec/describe_stacks.go (5)
pkg/schema/schema.go (2)
Context(480-495)Stacks(439-445)pkg/config/const.go (1)
NameSectionName(65-65)internal/exec/template_utils.go (1)
ProcessTmpl(53-97)internal/exec/stack_utils.go (1)
GetStackNamePattern(205-207)pkg/config/utils.go (2)
GetContextFromVars(640-668)GetContextPrefix(671-741)
internal/exec/stack_processor_process_stacks.go (1)
pkg/config/const.go (1)
NameSectionName(65-65)
internal/exec/stack_manifest_name_test.go (3)
pkg/schema/schema.go (1)
ConfigAndStacksInfo(621-716)internal/exec/utils.go (1)
FindStacksMap(262-312)internal/exec/describe_stacks.go (1)
ExecuteDescribeStacks(116-959)
🪛 LanguageTool
website/blog/2025-12-03-stack-manifest-name-override.mdx
[typographical] ~24-~24: To join two clauses or introduce examples, consider using an em dash.
Context: ...nt}-{environment}-{stage}` - Default - The basename of the stack file (zero-con...
(DASH_RULE)
[typographical] ~57-~57: To join two clauses or introduce examples, consider using an em dash.
Context: ... in this order: 1. name (highest) - Explicit name from stack manifest 2. **`...
(DASH_RULE)
[typographical] ~59-~59: To join two clauses or introduce examples, consider using an em dash.
Context: ... from atmos.yaml 3. name_pattern - Token pattern from atmos.yaml 4. **Def...
(DASH_RULE)
[typographical] ~60-~60: To join two clauses or introduce examples, consider using an em dash.
Context: ...pattern from atmos.yaml 4. Default - Basename of the stack file This means y...
(DASH_RULE)
[style] ~143-~143: 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: ...name field to any stack manifest that needs an explicit name. This feature is fully...
(EN_REPEATEDWORDS_NEED)
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Acceptance Tests (linux)
- GitHub Check: Acceptance Tests (windows)
- GitHub Check: Summary
🔇 Additional comments (23)
tests/fixtures/scenarios/stack-manifest-name/components/terraform/mock/main.tf (1)
1-17: Well-formed test fixture.Clean and minimal Terraform configuration that's appropriately scoped for testing the stack-manifest-name feature. Variables are properly typed with sensible defaults, and outputs correctly reference them.
pkg/datafetcher/schema/stacks/stack-config/1.0.json (1)
7-10: Stack manifestnamefield schema reads cleanly.New
nameproperty and the additionalrequired: ["name"]branch are consistent with existing schema patterns and safely extend validation for the override use case.Also applies to: 111-115
pkg/config/const.go (1)
64-66: Centralizing thenamesection key is spot on.Adding
NameSectionNamealongside other section-name constants is consistent and makes downstream usage safer.tests/fixtures/scenarios/stack-manifest-name/stacks/catalog/base.yaml (1)
1-10: Base catalog fixture looks consistent.Straightforward vars and
terraform.vpccomponent definition; fits existing fixture conventions and is enough to support the scenario.tests/fixtures/scenarios/stack-manifest-name/atmos.yaml (1)
1-12: Scenarioatmos.yamlis wired sensibly.Stack and component base paths plus include/exclude patterns align with other test configs and suit the stack-manifest-name scenario.
website/docs/learn/stacks/stacks.mdx (1)
106-108:nameoverride docs are clear and aligned with behavior.The added comment in the
stack.yamlexample and the Stack Attributes entry describe the precedence (name>name_template>name_pattern> filename) and impact on Terraform workspaces in a way that matches the new fixtures and intended semantics.Also applies to: 156-187
tests/fixtures/scenarios/stack-manifest-name/stacks/legacy-prod.yaml (1)
1-15: Legacy stack fixture cleanly exercises the override path.Custom
name, import, vars, and component config are all minimal and focused, ideal for testing the manifest-name precedence.tests/fixtures/scenarios/stack-manifest-name/stacks/no-name-prod.yaml (1)
1-13: Filename-fallback fixture nicely complements the override case.This stack omits
namewhile sharing the same catalog base, which is exactly what you need to validate the default slug behavior.pkg/schema/schema.go (1)
625-625: LGTM!The new
StackManifestNamefield is well-placed and documented. The inline comment clearly states its purpose and precedence, following the struct's existing patterns.internal/exec/stack_utils.go (1)
29-45: Clean implementation of the naming precedence.The logic correctly prioritizes
StackManifestNameover template and pattern-based naming. The comment clearly documents the precedence order, and the fallback chain remains intact.website/blog/2025-12-03-stack-manifest-name-override.mdx (1)
1-143: Well-structured blog post documenting the feature.The post covers the problem, solution, use cases, and precedence clearly. The YAML examples are practical for the migration scenarios described.
One quick check: verify that
featureexists inwebsite/blog/tags.ymlandostermanexists inwebsite/blog/authors.ymlbefore merging, per the updated CLAUDE.md guidelines.CLAUDE.md (1)
420-438: Good documentation tightening.Mandating that blog posts use predefined tags and authors from the YAML files reduces inconsistency. The categorization between user-facing and internal tags is clear.
internal/exec/stack_manifest_name_test.go (3)
15-55: Solid test coverage for the name field extraction.The test correctly validates that the
namefield is present and has the expected value. The helper function is clean for logging purposes.
57-98: Good precedence verification.This test validates the core behavior: manifest name takes precedence over filename, and stacks without a custom name use the filename. The assertions cover both positive and negative cases.
100-148: Workspace derivation test is thorough. Verifies that the Terraform workspace correctly uses the manifest-provided name by testing against the actual fixture with custom name override (my-legacy-prod-stack), which is the key integration point for this feature. The fixture directory and all supporting files are properly configured.internal/exec/describe_stacks.go (8)
149-149: Variable declaration is appropriately scoped.
157-163: Clean extraction of the manifest-level name.Using the
cfg.NameSectionNameconstant keeps the key consistent across the codebase. The reset to empty string at the start of each iteration prevents cross-contamination between stacks.
264-290: StackManifestName correctly propagated to configAndStacksInfo.This ensures downstream processing (including workspace derivation) has access to the manifest override.
304-322: Precedence logic is correct for Terraform components.The explicit else clause defaulting to
stackFileNamemakes the logic complete. The comment clearly documents the precedence order.Based on learnings, the similar logic in Helmfile and Packer sections is intentionally not extracted into a helper function.
512-538: Helmfile section mirrors Terraform correctly.StackManifestName is propagated and precedence follows the same pattern.
552-570: Helmfile precedence logic matches Terraform.
737-763: Packer section correctly propagates StackManifestName.
777-795: Packer precedence logic completes the trio.All three component types now respect the same stack name precedence, ensuring consistent behavior across Terraform, Helmfile, and Packer.
|
💥 This pull request now has conflicts. Could you fix it @osterman? 🙏 |
Introduces a top-level `name` field in stack manifests that allows explicit control over logical stack names. This takes precedence over `name_template` and `name_pattern` from atmos.yaml, providing an escape hatch for legacy infrastructure or migrations from other tools. Stack name precedence: 1. `name` (highest) - Explicit name from stack manifest 2. `name_template` - From atmos.yaml, Go template 3. `name_pattern` - From atmos.yaml, token replacement 4. Default - Basename of the stack file (zero-config) - Add NameSectionName constant to pkg/config/const.go - Add StackManifestName field to ConfigAndStacksInfo struct - Update describe_stacks.go with name precedence logic for Terraform, Helmfile, Packer - Update BuildTerraformWorkspace in stack_utils.go to use manifest name - Extract and propagate name field in stack processing - Update JSON schema for stack manifests - Add comprehensive tests with fixtures - Document feature in stacks.mdx - Update CLAUDE.md with blog post tag guidance 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
…guide - Create website/docs/stacks/name.mdx documenting the `name` stack manifest field - Present choice between `name_template` (declarative) vs `name` (imperative) - Add "Stack Naming for Migrations" section to Terragrunt migration guide - Update stacks overview to include `name` in configuration sections table - Update learn/stacks/stacks.mdx with precedence order and links - Fix broken documentation links in blog post 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Lead with practical reason first - every Atmos command requires a stack name. Workspace convention is secondary consideration. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
osterman
force-pushed
the
osterman/stack-manifest-name
branch
from
f5977d9 to
370fc5b
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
website/docs/learn/stacks/stacks.mdx (1)
55-62: Documentation looks solid.The precedence order is clear and matches the implementation. One small typographical improvement per static analysis: consider using an em dash (—) instead of a hyphen for "Default — basename of the stack file" for better readability.
-4. **Default** - basename of the stack file +4. **Default** — basename of the stack fileinternal/exec/stack_manifest_name_test.go (1)
48-55: Helper function is fine for debugging.Simple utility for logging map keys. Consider using
maps.Keysfrom the standard library if Go 1.23+ is the minimum version, but this is minor.internal/exec/describe_stacks.go (1)
328-330: Redundant fallback check.Line 328-330 checks
if stackName == ""and falls back tostackFileName. However, the precedence logic on lines 304-322 already guaranteesstackNameis set tostackFileNamein the final else branch. This check is now unreachable unlessProcessTmplorGetContextPrefixreturn empty strings.Consider if this safety net is still needed or if it could be removed for clarity.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (18)
CLAUDE.md(1 hunks)internal/exec/describe_stacks.go(7 hunks)internal/exec/stack_manifest_name_test.go(1 hunks)internal/exec/stack_processor_process_stacks.go(2 hunks)internal/exec/stack_utils.go(1 hunks)pkg/config/const.go(1 hunks)pkg/datafetcher/schema/stacks/stack-config/1.0.json(2 hunks)pkg/schema/schema.go(1 hunks)tests/fixtures/scenarios/stack-manifest-name/atmos.yaml(1 hunks)tests/fixtures/scenarios/stack-manifest-name/components/terraform/mock/main.tf(1 hunks)tests/fixtures/scenarios/stack-manifest-name/stacks/catalog/base.yaml(1 hunks)tests/fixtures/scenarios/stack-manifest-name/stacks/legacy-prod.yaml(1 hunks)tests/fixtures/scenarios/stack-manifest-name/stacks/no-name-prod.yaml(1 hunks)website/blog/2025-12-03-stack-manifest-name-override.mdx(1 hunks)website/docs/learn/stacks/stacks.mdx(3 hunks)website/docs/migration/terragrunt.mdx(1 hunks)website/docs/stacks/name.mdx(1 hunks)website/docs/stacks/stacks.mdx(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (6)
- tests/fixtures/scenarios/stack-manifest-name/stacks/catalog/base.yaml
- internal/exec/stack_utils.go
- internal/exec/stack_processor_process_stacks.go
- tests/fixtures/scenarios/stack-manifest-name/stacks/legacy-prod.yaml
- pkg/config/const.go
- tests/fixtures/scenarios/stack-manifest-name/components/terraform/mock/main.tf
🧰 Additional context used
📓 Path-based instructions (7)
website/**
📄 CodeRabbit inference engine (.cursor/rules/atmos-rules.mdc)
website/**: Update website documentation in thewebsite/directory when adding new features, ensure consistency between CLI help text and website documentation, and follow the website's documentation structure and style
Keep website code in thewebsite/directory, follow the existing website architecture and style, and test website changes locally before committing
Keep CLI documentation and website documentation in sync and document new features on the website with examples and use cases
Files:
website/docs/learn/stacks/stacks.mdxwebsite/docs/migration/terragrunt.mdxwebsite/docs/stacks/stacks.mdxwebsite/blog/2025-12-03-stack-manifest-name-override.mdxwebsite/docs/stacks/name.mdx
website/**/*.mdx
📄 CodeRabbit inference engine (CLAUDE.md)
Verify website builds after doc changes: cd website && npm run build. Check for broken links, missing images, MDX component rendering
Files:
website/docs/learn/stacks/stacks.mdxwebsite/docs/migration/terragrunt.mdxwebsite/docs/stacks/stacks.mdxwebsite/blog/2025-12-03-stack-manifest-name-override.mdxwebsite/docs/stacks/name.mdx
**/*.go
📄 CodeRabbit inference engine (.cursor/rules/atmos-rules.mdc)
**/*.go: Use Viper for managing configuration, environment variables, and flags in CLI commands
Use interfaces for external dependencies to facilitate mocking and consider using testify/mock for creating mock implementations
All code must pass golangci-lint checks
Follow Go's error handling idioms: use meaningful error messages, wrap errors with context usingfmt.Errorf("context: %w", err), and consider using custom error types for domain-specific errors
Follow standard Go coding style: usegofmtandgoimportsto format code, prefer short descriptive variable names, use kebab-case for command-line flags, and snake_case for environment variables
Document all exported functions, types, and methods following Go's documentation conventions
Document complex logic with inline comments in Go code
Support configuration via files, environment variables, and flags following the precedence order: flags > environment variables > config file > defaults
Provide clear error messages to users, include troubleshooting hints when appropriate, and log detailed errors for debugging
**/*.go: Define interfaces for all major functionality and use dependency injection for testability
Generate mocks with go.uber.org/mock/mockgen using //go:generate directives. Never use manual mocks
Use functional options pattern to avoid functions with many parameters. Implement Option functions for config customization
Use context.Context as first parameter for cancellation signals, deadlines/timeouts, and request-scoped values. Do NOT use context for configuration, dependencies, or avoiding proper function parameters
Separate I/O (streams) from UI (formatting). Use data.* functions for pipeable output to stdout, ui.* functions for human UI messages to stderr
Use gitleaks library pattern masking with configurable categories (aws, github, generic). Disable with --mask=false flag
All comments must end with periods. Enforced by godot linter
NEVER delete existing comments without strong reason. Pre...
Files:
pkg/schema/schema.gointernal/exec/stack_manifest_name_test.gointernal/exec/describe_stacks.go
pkg/**/*.go
📄 CodeRabbit inference engine (CLAUDE.md)
pkg/**/*.go: Create purpose-built packages instead of adding to pkg/utils/ bloat. New functionality should go to pkg/newfeature/
Follow multi-provider registry pattern: 1) Define interface in dedicated package, 2) Implement per provider, 3) Register implementations, 4) Generate mocks
Files:
pkg/schema/schema.go
**/*_test.go
📄 CodeRabbit inference engine (.cursor/rules/atmos-rules.mdc)
**/*_test.go: Every new feature must include comprehensive unit tests targeting >80% code coverage for all packages
Use table-driven tests for testing multiple scenarios in Go
Include integration tests for command flows and test CLI end-to-end when possible with test fixtures
**/*_test.go: Prefer unit tests with mocks over integration tests. Use interfaces + dependency injection for testability. Target >80% coverage
Test behavior, not implementation. Never test stub functions - implement or remove. Avoid tautological tests. Make code testable using DI to avoid os.Exit, external systems
Table-driven tests must have real scenarios, not stub functions. Use assert.ErrorIs(err, ErrSentinel) for our/stdlib errors; string matching OK for third-party
Tests must call actual production code, never duplicate logic. No coverage theater - validate real behavior
Use t.Skipf("reason") with clear context for test skipping. CLI tests auto-build temp binaries
NEVER manually edit golden snapshot files. Always use -regenerate-snapshots flag. Never pipe output with redirection (2>&1, | head, | tail) when running tests - breaks TTY detection
Bug fixing workflow: 1) Write failing test, 2) Run test to confirm failure, 3) Fix iteratively, 4) Verify full test suite. Test describes expected behavior
Files:
internal/exec/stack_manifest_name_test.go
internal/exec/**/*.go
📄 CodeRabbit inference engine (CLAUDE.md)
New configs support Go templating with FuncMap() from internal/exec/template_funcs.go
Files:
internal/exec/stack_manifest_name_test.gointernal/exec/describe_stacks.go
website/blog/**/*.mdx
📄 CodeRabbit inference engine (CLAUDE.md)
website/blog/**/*.mdx: Follow PR template (what/why/references). PRs labeled minor/major MUST include blog post: website/blog/YYYY-MM-DD-feature-name.mdx. Use only existing tags from website/blog/*.mdx
Blog post template must have YAML front matter with slug, title, authors, tags, and use after intro. Author is committer's GitHub username added to website/blog/authors.yml
Use only existing blog tags: primary (feature, enhancement, bugfix), secondary (dx, security, documentation, core, breaking-change)
Files:
website/blog/2025-12-03-stack-manifest-name-override.mdx
🧠 Learnings (34)
📓 Common learnings
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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.
📚 Learning: 2024-11-13T21:37:07.852Z
Learnt from: Cerebrovinny
Repo: cloudposse/atmos PR: 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:
website/docs/learn/stacks/stacks.mdxinternal/exec/stack_manifest_name_test.gointernal/exec/describe_stacks.go
📚 Learning: 2025-09-24T20:45:40.401Z
Learnt from: Benbentwo
Repo: cloudposse/atmos PR: 1475
File: tests/fixtures/scenarios/atmos-auth/stacks/deploy/nonprod.yaml:3-4
Timestamp: 2025-09-24T20:45:40.401Z
Learning: In Atmos stack files, the correct syntax for importing other stack files is `import:` (singular), not `imports:` (plural). All stack files in the Atmos codebase consistently use `import:` followed by a list of paths to import.
Applied to files:
website/docs/learn/stacks/stacks.mdxwebsite/docs/migration/terragrunt.mdxtests/fixtures/scenarios/stack-manifest-name/atmos.yamlpkg/datafetcher/schema/stacks/stack-config/1.0.jsonwebsite/docs/stacks/name.mdx
📚 Learning: 2025-02-11T08:21:33.143Z
Learnt from: shirkevich
Repo: cloudposse/atmos PR: 1034
File: website/docs/core-concepts/projects/configuration/stores.mdx:173-177
Timestamp: 2025-02-11T08:21:33.143Z
Learning: The parameter for configuring stack path delimiter in store configurations is consistently named `stack_delimiter` (not `stacks_delimiter`) across all store types in Atmos.
Applied to files:
website/docs/learn/stacks/stacks.mdx
📚 Learning: 2024-10-20T00:41:57.135Z
Learnt from: haitham911
Repo: cloudposse/atmos PR: 731
File: internal/exec/validate_stacks.go:93-98
Timestamp: 2024-10-20T00:41:57.135Z
Learning: When downloading schema files in `internal/exec/validate_stacks.go`, use a consistent temporary file name to overwrite the file each time and avoid creating multiple temporary files.
Applied to files:
pkg/schema/schema.gointernal/exec/stack_manifest_name_test.gointernal/exec/describe_stacks.go
📚 Learning: 2025-12-06T14:23:24.504Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-06T14:23:24.504Z
Learning: Applies to website/blog/**/*.mdx : Follow PR template (what/why/references). PRs labeled minor/major MUST include blog post: website/blog/YYYY-MM-DD-feature-name.mdx. Use only existing tags from website/blog/*.mdx
Applied to files:
CLAUDE.mdwebsite/blog/2025-12-03-stack-manifest-name-override.mdx
📚 Learning: 2025-12-06T14:23:24.504Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-06T14:23:24.504Z
Learning: Applies to website/blog/**/*.mdx : Use only existing blog tags: primary (feature, enhancement, bugfix), secondary (dx, security, documentation, core, breaking-change)
Applied to files:
CLAUDE.md
📚 Learning: 2025-12-06T14:23:24.504Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-06T14:23:24.504Z
Learning: Applies to website/blog/**/*.mdx : Blog post template must have YAML front matter with slug, title, authors, tags, and use <!--truncate--> after intro. Author is committer's GitHub username added to website/blog/authors.yml
Applied to files:
CLAUDE.md
📚 Learning: 2025-11-29T17:35:01.177Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1819
File: website/blog/2025-10-13-introducing-atmos-auth.md:5-6
Timestamp: 2025-11-29T17:35:01.177Z
Learning: In the Atmos blog (website/blog/), blog post authors should be set to the actual content author (the person who wrote the feature/content), not generic organization names like "cloudposse" or "atmos". If the actual author differs from the PR opener, use the actual author. Authors must exist in website/blog/authors.yml.
Applied to files:
CLAUDE.md
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to website/** : Update website documentation in the `website/` directory when adding new features, ensure consistency between CLI help text and website documentation, and follow the website's documentation structure and style
Applied to files:
CLAUDE.md
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to CHANGELOG.md : Follow semantic versioning, update CHANGELOG.md with each release, and create GitHub releases with detailed release notes
Applied to files:
CLAUDE.md
📚 Learning: 2025-09-13T16:39:20.007Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1466
File: cmd/markdown/atmos_toolchain_aliases.md:2-4
Timestamp: 2025-09-13T16:39:20.007Z
Learning: In the cloudposse/atmos repository, CLI documentation files in cmd/markdown/ follow a specific format that uses " $ atmos command" (with leading space and dollar sign prompt) in code blocks. This is the established project convention and should not be changed to comply with standard markdownlint rules MD040 and MD014.
Applied to files:
website/docs/migration/terragrunt.mdxwebsite/docs/stacks/name.mdx
📚 Learning: 2025-03-18T12:26:25.329Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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:
website/docs/migration/terragrunt.mdxtests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-01-19T15:49:15.593Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 955
File: tests/snapshots/TestCLICommands_atmos_validate_editorconfig_--help.stdout.golden:0-0
Timestamp: 2025-01-19T15:49:15.593Z
Learning: In future commits, the help text for Atmos CLI commands should be limited to only show component and stack parameters for commands that actually use them. This applies to the example usage section in command help text.
Applied to files:
website/docs/migration/terragrunt.mdx
📚 Learning: 2025-09-27T20:50:20.564Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1533
File: pkg/config/load.go:585-637
Timestamp: 2025-09-27T20:50:20.564Z
Learning: In the cloudposse/atmos repository, command merging prioritizes precedence over display ordering. Help commands are displayed lexicographically regardless of internal array order, so the mergeCommandArrays function focuses on ensuring the correct precedence chain (top-level file wins) rather than maintaining specific display order.
Applied to files:
website/docs/migration/terragrunt.mdx
📚 Learning: 2025-10-07T00:25:16.333Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1498
File: website/src/components/Screengrabs/atmos-terraform-metadata--help.html:25-55
Timestamp: 2025-10-07T00:25:16.333Z
Learning: In Atmos CLI, subcommands inherit flags from their parent commands via Cobra's command inheritance. For example, `atmos terraform metadata --help` shows `--affected` and related flags inherited from the parent `terraform` command (defined in cmd/terraform.go), even though the metadata subcommand doesn't explicitly define these flags. This is expected Cobra behavior and auto-generated help screengrabs accurately reflect this inheritance.
Applied to files:
website/docs/migration/terragrunt.mdx
📚 Learning: 2024-12-01T00:33:20.298Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 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:
website/docs/migration/terragrunt.mdxinternal/exec/stack_manifest_name_test.gotests/fixtures/scenarios/stack-manifest-name/atmos.yamltests/fixtures/scenarios/stack-manifest-name/stacks/no-name-prod.yamlwebsite/docs/stacks/name.mdx
📚 Learning: 2025-12-06T14:23:24.504Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-06T14:23:24.504Z
Learning: Applies to internal/exec/**/*.go : New configs support Go templating with FuncMap() from internal/exec/template_funcs.go
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2025-12-06T14:23:24.504Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-06T14:23:24.504Z
Learning: Applies to **/*_test.go : Bug fixing workflow: 1) Write failing test, 2) Run test to confirm failure, 3) Fix iteratively, 4) Verify full test suite. Test describes expected behavior
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2024-12-07T16:16:13.038Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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/stack_manifest_name_test.gointernal/exec/describe_stacks.go
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to **/*_test.go : Include integration tests for command flows and test CLI end-to-end when possible with test fixtures
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2024-12-07T16:19:01.683Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 825
File: internal/exec/terraform.go:30-30
Timestamp: 2024-12-07T16:19:01.683Z
Learning: In `internal/exec/terraform.go`, skipping stack validation when help flags are present is not necessary.
Applied to files:
internal/exec/stack_manifest_name_test.gointernal/exec/describe_stacks.go
📚 Learning: 2025-12-06T14:23:24.504Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-06T14:23:24.504Z
Learning: Applies to **/*_test.go : Test behavior, not implementation. Never test stub functions - implement or remove. Avoid tautological tests. Make code testable using DI to avoid os.Exit, external systems
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2024-10-20T00:57:53.500Z
Learnt from: haitham911
Repo: cloudposse/atmos PR: 731
File: internal/exec/validate_stacks.go:0-0
Timestamp: 2024-10-20T00:57:53.500Z
Learning: In `internal/exec/validate_stacks.go`, when downloading the Atmos JSON Schema file to the temp directory, the temporary file is overwritten each time, so explicit removal is not necessary.
Applied to files:
internal/exec/stack_manifest_name_test.gotests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2024-10-31T19:23:45.538Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 727
File: internal/exec/terraform.go:65-66
Timestamp: 2024-10-31T19:23:45.538Z
Learning: The variable `shouldCheckStack` in `ExecuteTerraform` controls whether validation is performed.
Applied to files:
internal/exec/stack_manifest_name_test.go
📚 Learning: 2025-01-19T22:30:27.600Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 0
File: :0-0
Timestamp: 2025-01-19T22:30:27.600Z
Learning: The Atmos YAML function `!env` is used to retrieve environment variables and assign them to sections in stack manifests. It supports both simple types (string, number, boolean) and complex types (JSON-encoded lists, maps, objects).
Applied to files:
website/docs/stacks/stacks.mdx
📚 Learning: 2024-11-25T17:17:15.703Z
Learnt from: RoseSecurity
Repo: cloudposse/atmos PR: 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/stack-manifest-name/atmos.yaml
📚 Learning: 2025-09-10T21:17:55.273Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1466
File: toolchain/http_client_test.go:3-10
Timestamp: 2025-09-10T21:17:55.273Z
Learning: In the cloudposse/atmos repository, imports should never be changed as per samtholiya's coding guidelines.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-01-25T03:51:57.689Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 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/stack-manifest-name/atmos.yaml
📚 Learning: 2025-11-01T20:24:29.557Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1714
File: NOTICE:0-0
Timestamp: 2025-11-01T20:24:29.557Z
Learning: In the cloudposse/atmos repository, the NOTICE file is programmatically generated and should not be manually edited. Issues with dependency license URLs in NOTICE will be resolved when upstream package metadata is corrected.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-01-08T19:01:32.938Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 899
File: examples/tests/test-vendor/test-components/main.tf:1-7
Timestamp: 2025-01-08T19:01:32.938Z
Learning: In the examples/tests directory of the atmos project, code examples are intentionally kept minimal and simple to facilitate understanding. Avoid suggesting additional complexity or validations that might make the examples harder to follow.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-09-08T01:25:44.958Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/docs/cli/commands/toolchain/usage.mdx:117-121
Timestamp: 2025-09-08T01:25:44.958Z
Learning: Final XDG Base Directory Specification implementation for atmos toolchain is complete and verified: toolchain/xdg_cache.go provides GetXDGCacheDir() and GetXDGTempCacheDir() functions, all hardcoded ~/.cache/tools-cache paths have been replaced with XDG-compliant paths using ${XDG_CACHE_HOME}/atmos-toolchain (or ~/.cache/atmos-toolchain fallback), and tests have been updated to expect the new path structure.
Applied to files:
tests/fixtures/scenarios/stack-manifest-name/atmos.yaml
📚 Learning: 2025-06-23T02:14:30.937Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 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/describe_stacks.go
📚 Learning: 2024-12-03T04:01:16.446Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 810
File: website/docs/core-concepts/stacks/yaml-functions/terraform.output.mdx:0-0
Timestamp: 2024-12-03T04:01:16.446Z
Learning: In the `terraform.output.mdx` documentation file (`website/docs/core-concepts/stacks/yaml-functions/terraform.output.mdx`), the cache invalidation and cache scope behavior for the `!terraform.output` function are already described.
Applied to files:
website/blog/2025-12-03-stack-manifest-name-override.mdx
🧬 Code graph analysis (2)
internal/exec/stack_manifest_name_test.go (3)
pkg/schema/schema.go (1)
ConfigAndStacksInfo(621-716)internal/exec/utils.go (1)
FindStacksMap(262-312)internal/exec/describe_stacks.go (1)
ExecuteDescribeStacks(116-959)
internal/exec/describe_stacks.go (4)
pkg/config/const.go (1)
NameSectionName(65-65)internal/exec/template_utils.go (1)
ProcessTmpl(53-97)internal/exec/stack_utils.go (1)
GetStackNamePattern(205-207)pkg/config/utils.go (2)
GetContextFromVars(724-752)GetContextPrefix(755-825)
🪛 LanguageTool
website/docs/learn/stacks/stacks.mdx
[typographical] ~60-~60: To join two clauses or introduce examples, consider using an em dash.
Context: ...atmos.yaml(token-based) 4. **Default** - basename of the stack file Usename_te...
(DASH_RULE)
website/docs/migration/terragrunt.mdx
[style] ~918-~918: Try moving the adverb to make the sentence clearer.
Context: ...ion, use the name field in each stack manifest to explicitly specify the stack name: <File title="stacks/us-east-1/prod/vp...
(SPLIT_INFINITIVE)
[typographical] ~931-~931: Consider using a typographic opening quote here.
Context: ...orm: vpc: vars: cidr: "10.0.0.0/16" ``` This is the ri...
(EN_QUOTES)
[typographical] ~931-~931: Consider using a typographic close quote here.
Context: ...: vars: cidr: "10.0.0.0/16" ``` This is the right choice w...
(EN_QUOTES)
website/blog/2025-12-03-stack-manifest-name-override.mdx
[typographical] ~24-~24: To join two clauses or introduce examples, consider using an em dash.
Context: ...nt}-{environment}-{stage}` - Default - The basename of the stack file (zero-con...
(DASH_RULE)
[typographical] ~57-~57: To join two clauses or introduce examples, consider using an em dash.
Context: ... in this order: 1. name (highest) - Explicit name from stack manifest 2. **`...
(DASH_RULE)
[typographical] ~59-~59: To join two clauses or introduce examples, consider using an em dash.
Context: ... from atmos.yaml 3. name_pattern - Token pattern from atmos.yaml 4. **Def...
(DASH_RULE)
[typographical] ~60-~60: To join two clauses or introduce examples, consider using an em dash.
Context: ...pattern from atmos.yaml 4. Default - Basename of the stack file This means y...
(DASH_RULE)
[style] ~143-~143: 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: ...name field to any stack manifest that needs an explicit name. This feature is fully...
(EN_REPEATEDWORDS_NEED)
website/docs/stacks/name.mdx
[typographical] ~65-~65: Consider using a typographic opening quote here.
Context: ...orm: vpc: vars: cidr: "10.0.0.0/16" ``` With this conf...
(EN_QUOTES)
[typographical] ~65-~65: Consider using a typographic close quote here.
Context: ...: vars: cidr: "10.0.0.0/16" ``` With this configuration, t...
(EN_QUOTES)
[typographical] ~119-~119: Consider using a typographic opening quote here.
Context: ...orm: vpc: vars: cidr: "10.0.0.0/16" ``` This ensures `...
(EN_QUOTES)
[typographical] ~119-~119: Consider using a typographic close quote here.
Context: ...: vars: cidr: "10.0.0.0/16" ``` This ensures `atmos terraf...
(EN_QUOTES)
[typographical] ~164-~164: Consider using a typographic opening quote here.
Context: ...orm: vpc: vars: cidr: "10.0.0.0/16" ``` <File title="s...
(EN_QUOTES)
[typographical] ~164-~164: Consider using a typographic close quote here.
Context: ...: vars: cidr: "10.0.0.0/16" ``` <File title="stacks/legacy...
(EN_QUOTES)
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Acceptance Tests (linux)
- GitHub Check: Acceptance Tests (windows)
- GitHub Check: Summary
🔇 Additional comments (21)
CLAUDE.md (1)
420-440: Blog post guidance updates are well-structured and enforce centralized validation.The changes clearly direct contributors to use tags from
tags.ymland authors fromauthors.ymlrather than inventing new ones. The distinction between user-facing and internal tags, and theno-releaselabel for docs-only work, are all helpful clarifications. The example tag on line 429 is valid per the list.That said, these updates to
CLAUDE.mdare primarily documentation/process guidance and somewhat tangential to the core feature (manifest name field) introduced in this PR. Per learnings, changes to template contents and guidance are typically handled in dedicated PRs focused on those objectives. Consider whether this should be split into a separate maintenance PR, or if it's sufficiently foundational to this feature that it belongs here.Can you confirm whether
website/blog/tags.ymlandwebsite/blog/authors.ymlexist in the repo, and whether centralizing tag/author validation is a prerequisite for shipping the manifest name feature, or a nice-to-have improvement?website/docs/stacks/stacks.mdx (1)
21-27: Newnamesection entry looks consistent.Row points to
/stacks/name, describes the override accurately, and correctly scopes it to stack manifests only. Nicely keeps the sections overview in sync with the new feature.tests/fixtures/scenarios/stack-manifest-name/atmos.yaml (1)
1-12: Fixture atmos.yaml matches typical scenario layout.Base paths, include/exclude patterns, and Terraform component base path align with existing test scenarios and the new stack-manifest-name tests.
tests/fixtures/scenarios/stack-manifest-name/stacks/no-name-prod.yaml (1)
1-13: Good fixture for filename-based naming fallback.Comment clearly states intent,
import:syntax is correct for Atmos stacks, and the minimal component setup is enough to validate behavior when no manifestnameis present. Based on learnings, usingimport:(singular) is the right convention.pkg/schema/schema.go (1)
621-626: ConfigAndStacksInfo extension for manifest name is clean.Adding
StackManifestNamewith a clear inline comment is a straightforward way to carry the manifest override through processing, and it should not affect existing callers since the struct is extended, not reordered.website/docs/migration/terragrunt.mdx (1)
892-943: Stack naming section is accurate and migration-focused.The two-option breakdown (
name_templatevs explicitname) matches the documented precedence and gives practical Terragrunt-migration examples, with a good cross-link to the Stack Names doc.website/docs/stacks/name.mdx (1)
1-213: Stack naming doc is clear and aligned with behavior.Precedence, examples, and state/workspace implications all line up with the new manifest
namefeature and schema, and cross-links into related docs look correct.website/blog/2025-12-03-stack-manifest-name-override.mdx (1)
1-143: Blog post cleanly announces and explains the feature.Front matter follows the expected pattern, and the article’s description of precedence, use cases, and workspace effects matches the new Stack Names docs and schema changes.
pkg/datafetcher/schema/stacks/stack-config/1.0.json (1)
7-10: Schema updates correctly model the manifestnameoverride.Adding a top-level
nameproperty plus a correspondingrequired: ["name"]branch in theanyOfkeeps existing manifests valid while making the override explicit and discoverable for tooling.Also applies to: 112-116
website/docs/learn/stacks/stacks.mdx (2)
112-114: Good example placement.The commented example in the stack.yaml schema clearly shows the optional nature of the
namefield and its purpose.
162-193: Comprehensive attribute documentation.The
nameattribute section is well-structured with clear precedence order, practical example, and explanation of workspace behavior. This will help users understand the feature.internal/exec/stack_manifest_name_test.go (4)
15-46: Test validates name field in raw stacks map.This test confirms that
FindStacksMapincludes the rawnamefield from the manifest. The assertions are clear. One note: the conditional on line 43-45 means ifhasNameis false, you'd get an assertion failure but not the value check—currently correct behavior since theassert.Trueon line 42 would already fail.
57-98: Good coverage of stack name precedence.This test validates the core feature: stacks with
namefield use custom name as key, stacks without use filename, and original filename isn't used when custom name exists. Clean assertions.
100-148: Workspace derivation test is solid.Validates that Terraform workspace respects the manifest name—critical for the feature's stated purpose of workspace derivation. The deep map traversal is verbose but explicit.
17-18: The fixture directorytests/fixtures/scenarios/stack-manifest-nameexists with all necessary files (atmos.yaml, stack configurations, and terraform components). No action needed.internal/exec/describe_stacks.go (6)
149-149: Variable declaration is appropriate.Declaring
stackManifestNameat function scope allows it to be extracted once per stack file and reused across component types.
157-163: Clean extraction of manifest name.The nested type assertions safely extract the string value and default to empty string. This handles missing or non-string values gracefully.
264-290: StackManifestName correctly propagated to ConfigAndStacksInfo.The manifest name is passed through to downstream processing. This enables workspace derivation and other consumers to access the override.
304-322: Precedence logic is correct for Terraform components.The chain follows the documented order: manifest name → name_template → name_pattern → filename. The explicit else clause for default (line 319-321) improves clarity.
552-570: Helmfile precedence mirrors Terraform.Consistent implementation across component types. Based on learnings, the duplication is intentional.
777-795: Packer precedence completes the trio.All three component types now respect the same precedence order.
Add comprehensive unit tests for the stack name precedence logic in BuildTerraformWorkspace: - TestBuildTerraformWorkspace_StackManifestName: manifest name (highest) - TestBuildTerraformWorkspace_NameTemplate: name_template from atmos.yaml - TestBuildTerraformWorkspace_NamePattern: name_pattern from atmos.yaml - TestBuildTerraformWorkspace_DefaultFilename: filename fallback - TestBuildTerraformWorkspace_Precedence: table-driven test for all cases These tests improve coverage for the new StackManifestName field in stack_utils.go lines 30-35. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Add tests for ExecuteDescribeStacks that exercise the name_template and name_pattern branches in describe_stacks.go: - TestDescribeStacks_NameTemplate: Tests that stacks without explicit 'name' field use name_template from atmos.yaml - TestDescribeStacks_NameTemplateWorkspace: Verifies workspace names derive from name_template - TestDescribeStacks_NamePattern: Tests that stacks use name_pattern when no name or name_template is set - TestDescribeStacks_NamePatternWorkspace: Verifies workspace names derive from name_pattern Also adds two new test fixtures: - stack-manifest-name-template: atmos.yaml with name_template configured - stack-manifest-name-pattern: atmos.yaml with name_pattern configured Refactored tests to use helper functions to reduce code duplication. Converted if-else chains to switch statements to satisfy gocritic linter. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
github-actions
bot
added
size/xl
|
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. |
what
namefield in stack manifests for explicit control over logical stack namesname_templateandname_patternfrom atmos.yamlwhy
Stack naming conventions work well for greenfield projects but struggle with:
This feature allows selective stack name overrides without requiring all stacks to follow a pattern.
references
metadata.namefield for component renamingSummary by CodeRabbit
New Features
Documentation
Tests
✏️ Tip: You can customize this high-level summary in your review settings.