-
Notifications
You must be signed in to change notification settings - Fork 268
Fix load environment lazily to respect -e flag #6641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Stop injecting *environment.Environment in NewDeployAction and remove the stored env field. Resolve the environment at the start of DeployAction.Run (using envManager.Get with the parsed -e flag or azdCtx default) and use the resolved env for subscription checks, AspireDashboardUrl, cache invalidation, and follow-up output. This prevents the environment from being constructed before CLI flags are processed (fixes case where `-e` was ignored).
|
Thank you for your contribution @lim-dy! We will review the pull request and get back to you soon. |
|
/azp run azure-dev - cli |
|
Azure Pipelines successfully started running 1 pipeline(s). |
weikanglim
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @lim-dy ! Thanks for proposing the changes.
Could you file an issue with the repro steps and the specific azd version you may be using? I've tried running the same repro steps with azd deploy -e dev as provided, and it seems to be working as intended.
This also agrees with my understanding of how *environment.Environment is injected -- it parses the envFlag first before determining which environment to load. For these reasons, I'm holding off on approval for now.
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
This PR fixes a bug where running
azd deploy -e <env-name>would ignore the provided environment flag and instead deploy to the currently selected default environment.Root Cause:
The
DeployActionwas requesting the*environment.Environmentobject via constructor injection. The IoC container resolved this dependency eagerly (during application startup) before the command-line flags (specifically-e) were fully processed. As a result, the container fell back to the default environment stored in the local context, permanently binding the wrong environment to the action.The Fix:
NewDeployActionto remove the eager injection of*environment.Environment.DeployActionto hold a reference toenvironment.Manager.Runmethod. The environment is now loaded lazily usingda.flags.EnvironmentName, ensuring the CLI flag is respected.Testing
Reproduction Steps (Before Fix):
devandprod.devas default:azd env select dev.azd deploy -e prod.dev(Incorrect).Verification (After Fix):
devandprod.devas default:azd env select dev.azd deploy -e prod.prod(Correct).Affected Commands
azd deploy