Stack name override not taken into account by atmos tf plan

[afeblot]

Describe the Bug

name can now be overridden in a stack definition. This is properly taken into account by atmos list stacks and atmos list values but not by atmos tf plan and atmos tf apply.

Expected Behavior

Stack name override is consistently taken into account in all atmos commands.

Steps to Reproduce

tar xvf name_bug.tar.gz

$ atmos list values myapp

 Key    dev-custom  prod 
─────────────────────────
 stage  dev         prod 

$ atmos list stacks

 Stack      
────────────
 dev-custom 
 prod       

$ atmos tf plan myapp -s dev-custom

 Error 

 Error: invalid component

## Explanation

 Could not find the component  myapp  in the stack  dev-custom .
 Check that all the context variables are correctly defined in the stack manifests.
 Are the component and stack names correct? Did you forget an import?

$ atmos tf plan myapp -s dev

Initializing the backend...

Initializing provider plugins...
- terraform.io/builtin/terraform is built in to OpenTofu
OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

OpenTofu will perform the following actions:

  # terraform_data.helloworld will be created
  + resource "terraform_data" "helloworld" {
      + id = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Screenshots

No response

Environment

• Atmos 1.203.0
• WSL2 / Ubuntu 22.04

Additional Context

No response

[osterman]

@afeblot are you able to test/validate #1934?

[afeblot]

@osterman, with the binary downloaded from your PR build, ./atmos-pr1934 tf plan myapp -s STACK_NAME works fine for both -s dev-custom (which is what I expected) and -s dev (which probably should rather return an error ?)

$ ./atmos-pr1934 tf plan myapp -s dev

Initializing the backend...

Initializing provider plugins...
- terraform.io/builtin/terraform is built in to OpenTofu

OpenTofu has been successfully initialized!
Switched to workspace "dev-custom".

OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

OpenTofu will perform the following actions:

  # terraform_data.helloworld will be created
  + resource "terraform_data" "helloworld" {
      + id = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.
╷
│ Warning: Value for undeclared variable
│ 
│ The root module does not declare a variable named "stage" but a value was found in file "dev-myapp.terraform.tfvars.json". If you meant to use this value, add a "variable" block to the configuration.
│ 
│ To silence these warnings, use TF_VAR_... environment variables to provide certain "global" settings to all configurations in your organization. To reduce the verbosity of these warnings, use the -compact-warnings
│ option.

[osterman]

works fine for both -s dev-custom (which is what I expected) and -s dev (which probably should rather return an error ?)

That's a good catch that was not taken into account in the original design.

We've documented the intended behavior and fixed the resolution.

See PRD

And also please see if this works more as expected.

[afeblot]

Vibe coding requires more effort on testing ;-)

[afeblot]

But yes, now, it behaves as I thought it should.

[osterman]

Vibe coding requires more effort on testing ;-)

You’re not wrong.

We are shipping some things that are premature and insufficiently QA’d.

Overall I think we’re doing a lot right, but we’re still playing catch-up in a few areas:

• QA — we need more hands to keep pace (thank you for your help)
• Release strategy — stronger stable/release branches, and likely fewer “minor” drops with more meaningful releases
• Feature flagging — so we can land work safely without forcing it on everyone

Really appreciate you opening all the issues. It’s helping us tighten this up quickly. We commit fixing issues promptly.

I would expect a little more instability as we work through more core improvements over the coming months, before it settles down.

Thanks again, and hope you can bare with us.

[osterman]

Feature flagging — so we can land work safely without forcing it on everyone

See:

• feat: Add experimental feature transparency and controls #1940