Fix: Ensure azd up -e deploys resources to the specified environment, ignoring the default environment
#4561
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Menghua1
requested review from
ellismg,
wbreza,
vhvb1989,
hemarina and
weikanglim
as code owners
1 task
vhvb1989
reviewed
Nov 15, 2024
cli/azd/cmd/up.go
Outdated
| stepArgs := append(step.AzdCommand.Args, "-e", envValue) | ||
| step.AzdCommand.Args = stepArgs | ||
| } | ||
| } |
There was a problem hiding this comment.
Since -e is a global flag, we should not manually set it like this. It should be already visible to all commands.
There was a problem hiding this comment.
@vhvb1989 Thanks for your feedback!
When debugging the azd up -e <environment> command, we found that the actual executed steps (such as azd package, azd provision, and azd deploy) did not include the -e flag, which caused these commands to use the default environment instead of the environment specified by the user through -e. To ensure that these subcommands can correctly use the environment specified by -e, I manually set it in the code.
If you think there is a better solution, you are welcome to discuss further in the issue #4411 (comment)!
There was a problem hiding this comment.
The current solution wouldn't work if the user added the workflow step to reference an azd command not accepting -e. An immediate solution doesn't come to mind, but will require some additional team discussion.
Switch default environment to the one specified by -e if it exists
Menghua1
force-pushed
the
fix-issue#4411
branch
from
795b6f1 to
3d81193
Compare
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
vhvb1989
reviewed
Jan 16, 2025
| } | ||
|
|
||
| if env.Name() != defaultEnvironmentName { | ||
| if err := m.azdContext.SetProjectState(azdcontext.ProjectState{DefaultEnvironment: env.Name()}); err != nil { |
There was a problem hiding this comment.
I actually like this approach. The side effect is that running one command with the -e foo flag makes the foo environment the default one, which also means that the last environment you use is always now the default environment.
That's probably a breaking change for someone running something like
azd env new foo
azd env ser a 1
azd provision -e bar
azd provision // expecting to use environment foo but bar will be used instead as the default
There was a problem hiding this comment.
That's probably a breaking change for someone running something like
azd env new foo
azd env ser a 1
azd provision -e bar
azd provision // expecting to use environment foo butbarwill be used instead as the default
@vhvb1989 According to the azd logic, when executing the azd provision -e bar command,
-
If the
barenvironment does not exist, azd sets it as the default environment, and the default environment isbar. -
If the
barenvironment already exists and is not the default environment, azd will not switch the default environment, and the default environment isfoo.
The processing logic in these two cases is inconsistent, which may cause confusion to users.
Therefore, I think we need to adjust the logic of azd to ensure the consistency of its behavior. Regardless of whether the environment specified by the user already exists, as long as the user executes a command with the -e flag, azd should follow a consistent behavior: either do not change the default environment, or set the specified environment as the default environment in any case.
There was a problem hiding this comment.
You are right. Whenever azd creates a new environment, either with azd env new or from azd provision -e new-env, that environment is set as the default environment. Create new environment is expected to have this effect.
In all other cases, the default environment should not be changed.
It's definitely somehow confusing and probably azd should ask/confirm before setting a recent created environment as the new default. #4800
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix issue#4411.
@rajeshkamal5050 for notification.