Replace ensureProject with NewAzdContext validation#1296
Conversation
ellismg
left a comment
There was a problem hiding this comment.
Love it! Some non-blocking feedback around exporting an error.
wbreza
left a comment
There was a problem hiding this comment.
Looks good - one question around usage of azd context.
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSIContainerDocumentationlearn.microsoft.com documentationtitle: Azure Developer CLI Preview reference
|
In Azure#1296 we changed our logic such that we would inject `AzdContext` as a depenecy of our actions, and expect our IoC container to wire things up. This had the side effect of breaking `azd up --template` to initilize (and then provison and deploy) a new project. The break comes from the fact that the IoC container will call `NewAzdContext` as part of building the `deploy` and `infraCreate` actions, which need to be created because they are dependencies of the `up` composite action. However, `NewAzdContext` should not be called before the project has actually been created (which will happen when the `up` composite action calls the `init` action), because it looks for an existing project and if it doesn't find one it fails. To work around this issue - I've made the infra create and deploy actions explicitly call `NewAzdContext` so the calls can happen at the right time. A regression test has been added (it's a little hacky because we don't actually care about running the `infra create` or `deploy` parts of `up` in this test, we just want to ensure that we correctly initialized via a template. Fixes Azure#1329
In Azure#1296 we changed our logic such that we would inject `AzdContext` as a depenecy of our actions, and expect our IoC container to wire things up. This had the side effect of breaking `azd up --template` to initilize (and then provison and deploy) a new project. The break comes from the fact that the IoC container will call `NewAzdContext` as part of building the `deploy` and `infraCreate` actions, which need to be created because they are dependencies of the `up` composite action. However, `NewAzdContext` should not be called before the project has actually been created (which will happen when the `up` composite action calls the `init` action), because it looks for an existing project and if it doesn't find one it fails. To work around this issue - I've made the infra create and deploy actions explicitly call `NewAzdContext` so the calls can happen at the right time. A regression test has been added (it's a little hacky because we don't actually care about running the `infra create` or `deploy` parts of `up` in this test, we just want to ensure that we correctly initialized via a template. Fixes Azure#1329
In Azure#1296 we changed our logic such that we would inject `AzdContext` as a depenecy of our actions, and expect our IoC container to wire things up. This had the side effect of breaking `azd up --template` to initilize (and then provison and deploy) a new project. The break comes from the fact that the IoC container will call `NewAzdContext` as part of building the `deploy` and `infraCreate` actions, which need to be created because they are dependencies of the `up` composite action. However, `NewAzdContext` should not be called before the project has actually been created (which will happen when the `up` composite action calls the `init` action), because it looks for an existing project and if it doesn't find one it fails. To work around this issue - I've made the infra create and deploy actions explicitly call `NewAzdContext` so the calls can happen at the right time. A regression test has been added (it's a little hacky because we don't actually care about running the `infra create` or `deploy` parts of `up` in this test, we just want to ensure that we correctly initialized via a template. Fixes Azure#1329
In #1296 we changed our logic such that we would inject `AzdContext` as a dependency of our actions, and expect our IoC container to wire things up. This had the side effect of breaking `azd up --template` to initialize (and then provision and deploy) a new project. The break comes from the fact that the IoC container will call `NewAzdContext` as part of building the `deploy` and `infraCreate` actions, which need to be created because they are dependencies of the `up` composite action. However, `NewAzdContext` should not be called before the project has actually been created (which will happen when the `up` composite action calls the `init` action), because it looks for an existing project and if it doesn't find one it fails. To work around this issue - I've made the infra create and deploy actions explicitly call `NewAzdContext` so the calls can happen at the right time. A regression test has been added (it's a little hacky because we don't actually care about running the `infra create` or `deploy` parts of `up` in this test, we just want to ensure that we correctly initialized via a template. Fixes #1329
Remove the need to call
ensureProjecteverywhere in favor of construction validation in theNewAzdContextconstructor.The only place we need to create an
azdContextwithout validation is ininit, which uses a directNewAzdContextWithDirectoryconstruction.Address #1295 partially