You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
# 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
The text was updated successfully, but these errors were encountered: