Open nitrocode opened 7 months ago
That's an interesting use-case. Let me take my spin, use names that are more familiar based on company history. So canonical names can be programmatically consistent, but teams can use other conventions that make more sense in their business context.
Would the aliases be defined in the stack configuration?
components:
terraform:
s3-bucket/test:
settings:
aliases:
- dev-01
- dev-icons
vars:
# Canonical stack slug is ue1-dev-assets
namespace: ue1
stage: dev
name: assets
Could be executed in the following ways:
# Using the canonical stack slug `ue1-dev-assets`
atmos terraform plan s3-bucket/test --stack ue1-dev-assets
# For "historical reasons", devs call it "dev-icons"
atmos terraform plan s3-bucket/test --stack dev-icons
I could see aliases
being only valid in the settings
block being ignored from all imports, because an alias would never be relative to it's stack context.
Describe the Feature
I like using
ue1-dev
ororg-ue1-dev
, but it would be nice to alias themso then we could have
Expected Behavior
Use Case
Easier for devs to use older account names that may not match the shortest stage names
Existing account names can be too long where if they were used as
stage
then aws resources are more likely to hit max character restraintsDescribe Ideal Solution
See above
Alternatives Considered
No response
Additional Context
No response