Fix load environment lazily to respect -e flag#6641
Fix load environment lazily to respect -e flag#6641lim-dy wants to merge 3 commits intoAzure:mainfrom
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). |
There was a problem hiding this comment.
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.
EDIT: @JeffreyCA mentioned a potential bug with container_helper.go that may explain what you're seeing. I submitted #6649 as a potential fix.
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
… environment confusion bugs (#6649) Refactored `ContainerHelper` to accept `*environment.Environment` explicitly in method signatures instead of implicitly resolving it via `getCurrentEnvironment()`. This fixes a bug where the helper was always fetching the default environment, makes it stateless and reusable as library code. The issue in #6019 is not regressed since `container_service.go` continues to observe the environment updates using `*lazy.Lazy[*environment.Environment]`. Fixes a concern raised in #6641
|
Closing in favor of #6649 |
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