Update stacks.name_template. Update docs
#1264
Conversation
📝 WalkthroughWalkthroughThis update introduces support for stack name templates in stack and component processing, adds a new accessor for stack name templates, updates related documentation, and provides comprehensive test fixtures and tests for the new functionality. Several dependencies are also bumped in the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant ComponentProcessor
participant StackUtils
User->>ComponentProcessor: ProcessComponentFromContext(ctx, atmosConfig, ...)
ComponentProcessor->>StackUtils: GetStackNameTemplate(atmosConfig)
StackUtils-->>ComponentProcessor: stackNameTemplate
ComponentProcessor->>StackUtils: GetStackNamePattern(atmosConfig)
StackUtils-->>ComponentProcessor: stackNamePattern
alt stackNameTemplate is set
ComponentProcessor->>ComponentProcessor: Render stack name using template and context
else stackNamePattern is set
ComponentProcessor->>ComponentProcessor: Derive stack name using pattern and context
else
ComponentProcessor->>ComponentProcessor: Return error (missing template/pattern)
end
ComponentProcessor-->>User: Component configuration (or error)
Possibly related PRs
Suggested labels
Suggested reviewers
Note ⚡️ AI Code Reviews for VS Code, Cursor, WindsurfCodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback. Note ⚡️ Faster reviews with cachingCodeRabbit now supports caching for code and dependencies, helping speed up reviews. This means quicker feedback, reduced wait times, and a smoother review experience overall. Cached data is encrypted and stored securely. This feature will be automatically enabled for all accounts on May 30th. To opt out, configure 📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🧰 Additional context used🧬 Code Graph Analysis (1)pkg/component/component_processor_test.go (1)
⏰ Context from checks skipped due to timeout of 90000ms (2)
🔇 Additional comments (3)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1264 +/- ##
==========================================
+ Coverage 48.06% 48.57% +0.51%
==========================================
Files 233 233
Lines 25441 25461 +20
==========================================
+ Hits 12228 12368 +140
+ Misses 11624 11489 -135
- Partials 1589 1604 +15
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
tests/fixtures/scenarios/stack-name-template/atmos.yaml (2)
45-47: Unreachable tenant validation
This block checks for a non-emptytenantand an emptynamespace, but the previous guard already fails on an emptynamespace. As a result, this condition can never be hit. Consider removing lines 45–47 to simplify the template.
57-69: Simplify name concatenation with a join operation
Instead of multipleifandprintfcalls, you can streamline construction by collecting non-empty parts into a list and joining with a hyphen. For example:- {{- $stack_name := "" -}} - {{- if ne $tenant "" -}} - {{- $stack_name = $tenant -}} - {{- end -}} - {{- if ne $env "" -}} - {{- $stack_name = printf "%s-%s" $stack_name $env -}} - {{- end -}} - {{- if ne $stage "" -}} - {{- $stack_name = printf "%s-%s" $stack_name $stage -}} - {{- end -}} - {{- $stack_name -}} + {{- $parts := list $tenant $env $stage | compact -}} + {{- join "-" $parts -}}This reduces boilerplate and leverages Sprig/Gomplate filters for clarity.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (19)
go.mod(6 hunks)internal/exec/stack_utils.go(1 hunks)internal/exec/utils.go(2 hunks)pkg/component/component_processor.go(3 hunks)pkg/component/component_processor_test.go(1 hunks)tests/fixtures/scenarios/stack-name-template/atmos.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/catalog/c1.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/mixins/region/us-east-2.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/mixins/stage/dev.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/mixins/stage/prod.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/mixins/tenant/plat.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/_defaults.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/_defaults.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/dev/_defaults.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/dev/us-east-2.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/prod/_defaults.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/prod/us-east-2.yaml(1 hunks)website/docs/cli/configuration/configuration.mdx(1 hunks)website/docs/cli/configuration/stacks.mdx(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (3)
internal/exec/stack_utils.go (1)
pkg/schema/schema.go (2)
AtmosConfiguration(23-57)Stacks(312-318)
internal/exec/utils.go (1)
pkg/schema/schema.go (3)
Components(307-310)Stacks(312-318)Workflows(320-323)
pkg/component/component_processor.go (3)
internal/exec/stack_utils.go (2)
GetStackNameTemplate(193-195)GetStackNamePattern(188-190)internal/exec/template_utils.go (1)
ProcessTmpl(26-63)pkg/config/utils.go (1)
GetStackNameFromContextAndStackNamePattern(702-758)
🪛 GitHub Check: codecov/patch
pkg/component/component_processor.go
[warning] 86-88: pkg/component/component_processor.go#L86-L88
Added lines #L86 - L88 were not covered by tests
[warning] 93-95: pkg/component/component_processor.go#L93-L95
Added lines #L93 - L95 were not covered by tests
[warning] 97-99: pkg/component/component_processor.go#L97-L99
Added lines #L97 - L99 were not covered by tests
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Acceptance Tests (windows-latest, windows)
- GitHub Check: Summary
🔇 Additional comments (36)
tests/fixtures/scenarios/stack-name-template/stacks/mixins/stage/prod.yaml (1)
1-4: Looks good — stage mixin
This fixture correctly declaresstage: prodwith the proper schema reference.tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/_defaults.yaml (1)
1-4: Looks good — org defaults
Definesnamespace: acmeunder the correct schema and path.tests/fixtures/scenarios/stack-name-template/stacks/mixins/tenant/plat.yaml (1)
1-4: Looks good — tenant mixin
Thetenant: platvariable is set correctly and matches the test scenario.tests/fixtures/scenarios/stack-name-template/stacks/mixins/region/us-east-2.yaml (1)
1-5: Looks good — region mixin
Definesregion: us-east-2andenvironment: ue2with the proper schema header.tests/fixtures/scenarios/stack-name-template/stacks/catalog/c1.yaml (1)
1-11: Looks good — component fixture
The Terraform componentc1is declared with its vars (a,b,c,d) and includes the correct schema.tests/fixtures/scenarios/stack-name-template/stacks/mixins/stage/dev.yaml (1)
1-4: Looks good!This fixture file properly defines a
stagevariable with the valuedevand includes the correct schema reference for validation. It will help test the new stack name templating feature.internal/exec/stack_utils.go (2)
192-195: Good implementation of the name template accessorThe new function correctly handles the stack name template retrieval with a pointer parameter, which is more efficient for the large
atmosConfigstruct (5976 bytes) than passing by value.
187-190: Minor comment formatting update looks goodThe comment format update for consistency is appropriate.
tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/prod/us-east-2.yaml (1)
1-6: Proper fixture configuration for the stack template featureThis manifest correctly imports the necessary components for testing the stack name template functionality, including defaults, regional configuration, and catalog entries.
website/docs/cli/configuration/configuration.mdx (1)
616-623: Improved documentation format and contentThe change from paragraph format to a bulleted list improves readability, and the addition of explicit references to "Go
text/templatefunctions" and "Atmos Template Functions" with documentation links provides valuable context for users implementing the new stack name templating feature.tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/prod/_defaults.yaml (1)
1-5: Defaults file structure looks goodThe defaults file correctly establishes schema validation and imports the appropriate parent defaults and stage mixin. This follows the hierarchical configuration pattern needed for stack name templating.
tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/_defaults.yaml (1)
1-5: Tenant defaults configuration is properly structuredThe tenant-level defaults file correctly imports the organization defaults and tenant mixin, establishing the necessary configuration hierarchy for the stack name template testing.
tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/dev/_defaults.yaml (1)
1-5: Development environment defaults are correctly configuredThe development environment defaults file properly imports the tenant defaults and development stage mixin, continuing the configuration hierarchy needed for stack name templating.
tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/dev/us-east-2.yaml (1)
1-6: Stack manifest imports are well structuredThe stack manifest correctly composes the configuration by importing the appropriate defaults, region mixin, and catalog component, completing the configuration needed for testing the stack name template feature.
internal/exec/utils.go (1)
647-653: CLI configuration moved to end of processing flowThe Atmos CLI configuration is now added to the component section after all CLI variables and stack processing are complete, which is a logical improvement. This ensures all processing is finished before the configuration is integrated.
This change supports the new stack name template feature by ensuring the configuration is fully processed and available when needed.
pkg/component/component_processor_test.go (1)
185-203: Good test coverage for the new stack name template feature.The new test function clearly validates the core functionality of the stack name template feature by ensuring that variables from the context are correctly processed and accessible in the component map.
website/docs/cli/configuration/stacks.mdx (3)
104-107: Clear explanation of supported template functions.The documentation now explicitly lists all supported function libraries, providing users with a comprehensive understanding of available templating capabilities.
140-212: Excellent documentation with detailed example.The added example thoroughly demonstrates the hierarchical validation pattern and provides clear explanations of the template logic. The sample input and expected output make it easy for users to understand how the feature works in practice.
213-219: Clear guidance on template vs pattern precedence.The note about using either
name_patternorname_templateis well-structured and makes the precedence relationship clear.go.mod (8)
35-35: Dependency update: go-containerregistry.Updated from v0.20.3 to v0.20.4.
76-76: Dependency update: google.golang.org/api.Updated from v0.233.0 to v0.234.0.
89-89: Dependency update: cloud.google.com/go/compute/metadata.Updated from v0.6.0 to v0.7.0.
162-162: Dependency update: docker/cli.Updated from v27.5.0+incompatible to v28.1.1+incompatible.
164-164: Dependency update: docker/docker-credential-helpers.Updated from v0.8.2 to v0.9.3.
291-291: Dependency update: vbatts/tar-split.Updated from v0.11.6 to v0.12.1.
326-326: Dependency update: golang.org/x/tools.Updated from v0.31.0 to v0.33.0.
330-330: Dependency update: google.golang.org/genproto/googleapis/rpc.Updated to a newer commit.
pkg/component/component_processor.go (2)
12-12: Good addition of a descriptive error variable.The new error variable provides a clear message about the configuration requirement.
68-70: Proper implementation of template preference.The code correctly retrieves both template and pattern values, with template taking precedence in the following logic.
tests/fixtures/scenarios/stack-name-template/atmos.yaml (7)
1-2: Validate the base path usage
Usingbase_path: "./"is functionally identical to".". If consistency with other fixtures is desired, consider switching tobase_path: ".". Otherwise, this is correct.
3-10: Terraform component flags look good
Thecomponents.terraformsection correctly defines the paths and boolean flags for init, reconfigure, and backend file generation. Ensure these keys match the schema ininternal/exec/stack_utils.go.
11-24: Stacks inclusion/exclusion and comments are clear
Theincluded_paths/excluded_pathsarrays and accompanying environment‐variable comments accurately document override options. The note aboutname_patternprecedence is also clear.
25-34: Documentation pointers forname_templateare comprehensive
Links to Atmos, Sprig, and Gomplate functions—and the YAML multiline guide—provide all the context a user needs. Nicely done.
35-43: Namespace requirement enforcement is correct
The first guard (if eq $ns "") ensuresnamespaceis always set before proceeding. This aligns with the design that namespace is mandatory, even if not used in the final name.
49-55: Environment and stage dependency checks are solid
The checks for.vars.environmentand.vars.stagecorrectly enforce hierarchical dependencies on prior variables. Error messages are clear and user-friendly.
71-74: Verify log level casing
Thelevel: Infoentry may need to match the Atmos parser’s expected casing (e.g.infovs.Info). Please confirm that uppercaseInfois accepted or adjust to the canonical lowercase form.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
tests/fixtures/scenarios/stack-name-template/atmos.yaml (1)
34-70: Streamline template conditional logic
The initialif eq $ns ""check (lines 41–43) preempts the more specific tenant/env/stage validations, making them unreachable. Consider reordering or consolidating these checks to preserve granular errors. For example:@@ name_template: |- - {{- if eq $ns "" -}} - {{- fail "Error: 'namespace' is required." -}} - {{- end -}} + {{- if ne $tenant "" -}} + {{- if eq $ns "" -}} + {{- fail "Error: 'tenant' requires 'namespace'." -}} + {{- end -}} + {{- end -}} + {{- if ne $env "" -}} + {{- if or (eq $tenant "") (eq $ns "") -}} + {{- fail "Error: 'environment' requires 'tenant' and 'namespace'." -}} + {{- end -}} + {{- end -}} + {{- if ne $stage "" -}} + {{- if or (eq $env "") (eq $tenant "") (eq $ns "") -}} + {{- fail "Error: 'stage' requires 'environment', 'tenant', and 'namespace'." -}} + {{- end -}} + {{- end -}} + {{- if eq $ns "" -}} + {{- fail "Error: 'namespace' is required." -}} + {{- end -}}This arrangement surfaces the specific dependency errors before the catch-all namespace requirement.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (19)
go.mod(6 hunks)internal/exec/stack_utils.go(1 hunks)internal/exec/utils.go(2 hunks)pkg/component/component_processor.go(3 hunks)pkg/component/component_processor_test.go(1 hunks)tests/fixtures/scenarios/stack-name-template/atmos.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/catalog/c1.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/mixins/region/us-east-2.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/mixins/stage/dev.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/mixins/stage/prod.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/mixins/tenant/plat.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/_defaults.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/_defaults.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/dev/_defaults.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/dev/us-east-2.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/prod/_defaults.yaml(1 hunks)tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/prod/us-east-2.yaml(1 hunks)website/docs/cli/configuration/configuration.mdx(1 hunks)website/docs/cli/configuration/stacks.mdx(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (3)
internal/exec/stack_utils.go (1)
pkg/schema/schema.go (2)
AtmosConfiguration(23-57)Stacks(312-318)
internal/exec/utils.go (1)
pkg/schema/schema.go (3)
Components(307-310)Stacks(312-318)Workflows(320-323)
pkg/component/component_processor.go (3)
internal/exec/stack_utils.go (2)
GetStackNameTemplate(193-195)GetStackNamePattern(188-190)internal/exec/template_utils.go (1)
ProcessTmpl(26-63)pkg/config/utils.go (1)
GetStackNameFromContextAndStackNamePattern(702-758)
🪛 GitHub Check: codecov/patch
pkg/component/component_processor.go
[warning] 86-88: pkg/component/component_processor.go#L86-L88
Added lines #L86 - L88 were not covered by tests
[warning] 93-95: pkg/component/component_processor.go#L93-L95
Added lines #L93 - L95 were not covered by tests
[warning] 97-99: pkg/component/component_processor.go#L97-L99
Added lines #L97 - L99 were not covered by tests
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Acceptance Tests (windows-latest, windows)
- GitHub Check: Summary
🔇 Additional comments (28)
go.mod (1)
35-35:❓ Verification inconclusive
Dependency version bumps look solid.
The upgraded modules (e.g.,go-containerregistry,docker/cli,x/tools, etc.) align with the new templating logic and test fixtures. Please verify that no breaking changes were introduced in these patch/minor releases.Also applies to: 76-76, 89-89, 162-162, 164-164, 291-291, 326-326, 330-330
🏁 Script executed:
#!/bin/bash # Verify module integrity and run full test suite go mod tidy go test ./...Length of output: 64734
Integration tests require Terraform & atmos binary
Dependency version bumps look solid, but runninggo test ./...in a clean environment fails due to missing executables needed by integration tests. Please verify that in your CI/local setup:
- Terraform is installed and on your
$PATH.- The
atmosCLI binary is built and discoverable (e.g.,go build ./cmd/atmos).
Then re-run:go mod tidy go test ./...Applies also to bump lines 76, 89, 162, 164, 291, 326, 330.
tests/fixtures/scenarios/stack-name-template/stacks/mixins/stage/prod.yaml (1)
1-4: Production stage mixin is configured correctly.
The schema reference andvars.stage: proddeclaration follow the expected pattern for staging mixins.tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/_defaults.yaml (1)
1-4: Organization defaults look good.
Definingnamespace: acmewith the correct schema header sets up the right context for tenant and environment variables.tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/dev/_defaults.yaml (1)
3-6:✅ Verification successful
Verify the existence of the referenced stage mixin.
This defaults file importsmixins/stage/dev, but thedevmixin wasn’t included in the provided fixtures. Please confirm thattests/fixtures/scenarios/stack-name-template/stacks/mixins/stage/dev.yamlexists and is correctly named.
🏁 Script executed:
#!/bin/bash # Check for the dev stage mixin file fd --base-directory tests/fixtures/scenarios/stack-name-template/stacks/mixins/stage dev.yamlLength of output: 104
Stage
devmixin found
Thetests/fixtures/scenarios/stack-name-template/stacks/mixins/stage/dev.yamlfile exists as expected, so the import is correct. No changes needed.tests/fixtures/scenarios/stack-name-template/stacks/mixins/tenant/plat.yaml (1)
1-4: Tenant mixin is well-defined.
Thevars.tenant: platentry with the proper schema annotation fits the scenario’s requirements.tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/prod/_defaults.yaml (1)
1-5: Structure looks good.Clean YAML structure with proper schema reference and imports. This defaults file correctly establishes the configuration hierarchy by importing both the parent organization defaults and the production stage mixin.
tests/fixtures/scenarios/stack-name-template/stacks/catalog/c1.yaml (1)
1-10: Component definition is properly structured.This component definition follows good practices with schema validation reference and a clean variable structure. The simple variables will work well for testing the new stack name template functionality.
tests/fixtures/scenarios/stack-name-template/stacks/mixins/stage/dev.yaml (1)
1-4: Mixin looks good.Properly structured mixin file that defines the stage variable for development environments. This will be useful in the stack name template context.
internal/exec/stack_utils.go (1)
192-195: Good function implementation.The new function follows the existing pattern and properly returns the stack name template. Using a pointer parameter for the configuration is more efficient than passing by value, which aligns with best practices for large structs.
tests/fixtures/scenarios/stack-name-template/stacks/mixins/region/us-east-2.yaml (1)
1-5: Well-structured regional mixin with schema validation.This mixin correctly defines regional variables (
region: us-east-2andenvironment: ue2) and includes schema validation reference. The file structure follows best practices for region-specific configuration that will be imported by stack manifests.tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/prod/us-east-2.yaml (1)
1-6: Well-structured stack manifest with proper imports.This stack manifest correctly imports defaults, region-specific mixins, and components in a clean hierarchical structure. The imports follow a logical pattern from organizational defaults to regional specifics to catalog components.
tests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/_defaults.yaml (1)
1-5: Proper tenant defaults configuration with schema validation.This defaults file correctly imports organizational defaults and tenant-specific mixins, establishing a proper inheritance chain for the platform tenant. The schema validation reference is correctly included.
website/docs/cli/configuration/configuration.mdx (1)
616-623: Improved documentation clarity for template functions.The documentation has been enhanced by transforming a paragraph into a bulleted list and adding "Atmos Template Functions" with its link. This change improves readability and properly documents the new templating capabilities.
internal/exec/utils.go (2)
310-311: Grammatical improvement in comment.The addition of the definite article "the" improves the grammar of the comment.
647-654: Properly moved CLI config map assignment to final stage.The
atmos_cli_configmap is now correctly added to the component section at the end of the function, just before it returns. This ensures that all the necessary configuration context is included, which is essential for the new stack name template processing.The map includes all relevant configuration sections:
base_pathcomponentsstacks(which now contains the newname_templatefield)workflowstests/fixtures/scenarios/stack-name-template/stacks/orgs/acme/plat/dev/us-east-2.yaml (1)
1-6: Well-structured test fixture for stack name template scenario.The manifest correctly follows Atmos schema validation pattern and imports the expected components for testing the stack name template functionality.
pkg/component/component_processor_test.go (1)
185-203: Good test coverage for the new stack name template functionality.This test effectively validates that the component processor correctly handles stack name templates by:
- Setting up test variables (component, namespace, tenant, environment, stage)
- Verifying that these variables are correctly maintained in the processed component
The test ensures that stack names created from templates properly propagate context variables to components.
pkg/component/component_processor.go (3)
12-12: Appropriate error definition for missing configuration.Clear error message explaining that either
stacks.name_patternorstacks.name_templatemust be specified in the configuration.
68-70: Good implementation for retrieving stack name configuration.Correctly retrieves both template and pattern configurations to determine which approach to use for stack name resolution.
72-100:❓ Verification inconclusive
Well-structured logic for stack name resolution.
The switch statement properly implements the priority logic between template and pattern:
- Tries to use the template first if available
- Falls back to pattern if template is not provided
- Returns an error if neither is configured
The template context creation is clean and includes all necessary variables.
🏁 Script executed:
#!/bin/bash # Check for test coverage of error paths in the switch statement # Find uncovered error paths rg -A 2 "if err != nil" pkg/component/component_processor.go | grep -B 1 "return nil, err" | grep -v "^--$"Length of output: 290
Let’s verify whether there are tests covering those error paths in
pkg/component:
🏁 Script executed:
#!/bin/bash # List test files in pkg/component find pkg/component -type f -name "*_test.go" # Search tests for the key functions and error rg -n "ProcessTmpl" pkg/component --glob "*_test.go" rg -n "GetStackNameFromContextAndStackNamePattern" pkg/component --glob "*_test.go" rg -n "ErrMissingStackNameTemplateAndPattern" pkg/component --glob "*_test.go"Length of output: 304
Verify error-path test coverage
It looks like pkg/component/component_processor_test.go doesn’t reference ProcessTmpl, GetStackNameFromContextAndStackNamePattern, or ErrMissingStackNameTemplateAndPattern. Please confirm that tests cover all three error branches in the switch:
- Template resolution error (
ProcessTmplpath)- Pattern resolution error (
GetStackNameFromContextAndStackNamePatternpath)- Missing both template and pattern error (
ErrMissingStackNameTemplateAndPattern)If these aren’t covered, consider adding tests to exercise each error case.
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 86-88: pkg/component/component_processor.go#L86-L88
Added lines #L86 - L88 were not covered by tests
[warning] 93-95: pkg/component/component_processor.go#L93-L95
Added lines #L93 - L95 were not covered by tests
[warning] 97-99: pkg/component/component_processor.go#L97-L99
Added lines #L97 - L99 were not covered by testswebsite/docs/cli/configuration/stacks.mdx (3)
104-107: Comprehensive documentation of supported template functions.Clearly lists all supported template function libraries, making it easier for users to understand what's available.
140-212: Excellent detailed example with hierarchical validation.The example template demonstrates:
- Validation of dependencies between variables
- Progressive stack name construction
- Proper error messages for invalid configurations
This provides users with a practical implementation pattern they can adapt for their needs.
213-219: Clear documentation of template priority.The note effectively communicates that users should use either
name_patternorname_template, withname_templatetaking precedence when both are specified.tests/fixtures/scenarios/stack-name-template/atmos.yaml (5)
1-2: Confirm base_path resolution
Thebase_path: "./"setting is clear, but ensure the test harness interprets it relative to the scenario directory.
3-10: Approve Terraform component configuration
Flags likedeploy_run_init,apply_auto_approve, andauto_generate_backend_fileare set deliberately to control behavior in tests. Looks consistent with other scenarios.
11-18: Verify stack path globs
Theincluded_pathsandexcluded_pathspatterns seem correct. Ensure that your fixture stacks undertests/fixtures/scenarios/stack-name-template/stacks/match these globs.
19-33: Document precedence of name_template over name_pattern
The comments clearly explain thatname_templatetakes priority. This matches the PR objectives for backward compatibility and user guidance.
71-74: Approve logging configuration
Writing logs to stderr at theInfolevel aligns with other test fixtures. Please confirm the logging parser accepts the capitalized level.
what
stacks.name_templatewhy
For the remote-state terraform module and terraform-provider-utils, allow using the
stacks.name_templatesetting inatmos.yamlwith a limited context:.vars.namespace.vars.tenant.vars.environment.vars.stageThis will allow using
name_template(instead ofname_pattern) in both Atmos CLI and theremote-statemodule (to get the outputs of TF components)stacks.name_templateserves the same purpose asstacks.name_pattern(defines the naming convention for the top-level Atmos stacks), but provides much more functionality. Instead of using the predefined context variables as tokens, it uses Go templates.Atmos Template Functions, Sprig Functions, Gomplate Functions, and Gomplate Datasources are supported as well
name_templatecan have complex logic and use template expressions and functions. The following template defines aname_templatethat builds astack_namestring by validating and concatenating several input variables in a hierarchical order.It pulls values from the Atmos section
varsand assigns them to local template variables:namespacetenantenvironmentstageThe template enforces hierarchical dependencies between variables:
namespaceis requiredtenantis provided,namespacemust also be setenvironmentis provided, bothtenantandnamespacemust be setstageis provided, thenenvironment,tenant, andnamespacemust all be setIf validations pass, it constructs the
stack_nameprogressively:tenantif it existsenvironmentif it existsstageif it existsThe template outputs the resulting stack name. For example, if the variables are:
The resulting stack name will be
plat-ue2-prod.Summary by CodeRabbit