[Issue] azd up ignores --environment if default environment is missing

[paulbatum]

• Make sure you've installed the latest version using instructions in the wiki

Output from azd version
azd version 1.10.1 (commit 31409a3)

Describe the bug
If config.json refers to a default environment that no longer exists (lets call it foo), running azd up --environment bar will ignore the specified env and instead prompt you Environment 'foo' does not exist, would you like to create it? (Y/n)

To Reproduce
mkdir azdtest
cd azdtest
azd init -t hello-azd -e bar
azd env new foo
rd -r ..azure\foo
azd up -e bar

Expected behavior
It runs on azd up on environment bar

Actual behavior
It displays the following prompt:
Environment 'foo' does not exist, would you like to create it? (Y/n)

[rajeshkamal5050]

@v-xuto can you help triage this?

[Menghua1]

@rajeshkamal5050 We were able to reproduce this issue and have created a PR #4561 to fix it, please review.

[Menghua1]

@vhvb1989 For this issue, we have the following two points to discuss with you:

1. The reproduction steps for this issue are incorrect:

   Firstly, we think the current operation is incorrect. To create and deploy resources in the bar environment, the command azd env select bar should be used to switch the environment to bar, and then azd up should be run to create and deploy resources in that environment.

2. Design issues with azd up -e:

   We noticed that even when specifying -e bar with the command azd up -e bar, the resources are created and deployed in the default environment foo instead of the specified bar environment.

   Is this behavior expected?

   If not, when -e bar is specified, should it create and deploy resources in the bar environment, and should it also change the default environment to bar?

Which one do you prefer?

[vhvb1989]

We noticed that even when specifying -e bar with the command azd up -e bar, the resources are created and deployed in the default environment foo instead of the specified bar environment.

That's definitely a bug. It might be related to the Inversion Of Control (IoC) container works; Azd might be handling the -e flag to create a new env but the environment is not reload and keeps the one injected by the IoC. @wbreza , can you review #4561 and let us know if that's OK to fix this? or provide some guidance for a fix?

[wbreza]

A related issue is #3920 which occurs when an environment is not available in CI causes hooks to not run. I would urge us to revisit a fix similar to #3940 where we have a middleware that ensures an azd environment is always created based on the existing semantics such as the optional -e flag.

[Menghua1]

@wbreza and @vhvb1989 We have the following two ideas:

1. Change MustRegisterScoped to MustRegisterSingleton:

   By changing MustRegisterScoped to MustRegisterSingleton in the cli/azd/cmd/container.go file, the environment will only be initialized once and reused consistently across all commands. This ensures that the environment bar is correctly loaded and shared across all subsequent commands (such as azd package, azd provision, and azd deploy).
   

2. Switch the default environment to the environment bar specified by -e before the workflow step:

   If azd up -e bar contains the -e flag, first switch the default environment to bar, and then process the workflow steps in azd up.

What do you think of the above two points?

[Menghua1]

@wbreza and @vhvb1989 According to the investigation, the cause of this issue is that when IoC Container manages environment instances, if the environment specified by -e bar exists but is not the default environment, it will not switch to the target environment instance specified by -e flag, but continue to use the default environment foo. As a result, even when the user explicitly specifies the bar environment, the command erroneously runs in the default environment foo, which does not align with the user's expectations.

The latest fix is : If the environment specified by -e bar exists but is not the default environment, switch the default environment to bar to ensure that the command runs in the environment specified by the user.

The commit is here, please review it.