-
Notifications
You must be signed in to change notification settings - Fork 268
Allow hooks to run without initial .azure directory
#6277
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
Conversation
Co-authored-by: Wei Lim <weilim@microsoft.com>
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.
Thanks for getting the fix for this one out, @JeffreyCA ! I know users have found it confusing in the past, I do believe the current fix addresses the immediate painpoints. Awesome work!
Co-authored-by: Wei Lim <weikanglim@gmail.com>
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
* Partially revert to use lazy-loaded projectConfig * Remove env check
Fixes #3920
This PR revives the main changes from #4011 and addresses the issue where project-level hooks (for example,
preprovision) would not run when there was no existing.azureenvironment folder. This commonly occurs in CI/CD scenarios:.azure/….azd provision --no-promptis run withAZURE_ENV_NAMEset.Previously, the hooks middleware relied on lazily-resolved environment and project configuration. As a result, hooks that should have run on the very first
provision(such as pre-provision validation or setup) were ignored.What this change does
environment.Manager,*environment.Environment,*project.ProjectConfig) instead oflazy.Lazywrappers. This removes the extra lazy lookup layer that usedenvironment.Manager.Get(which only works when.azure/<env>already exists) and aligns the middleware with the same*environment.Environmentinstance that the rest of the command pipeline initializes viaLoadOrInitInteractive, so hooks now see newly created environments (including the first CI run withAZURE_ENV_NAME) instead of only environments that already existed on disk.Runmethod (addressing the review feedback from PR #4011) so that if the environment or project configuration is not yet available, the middleware logs a clear message and safely skips hook registration without panicking.azd provisionwithoutAZURE_ENV_NAMEsetazd provisionwithAZURE_ENV_NAMEsetGitHub Actions -
azd provisionwithAZURE_ENV_NAMEset