-
Notifications
You must be signed in to change notification settings - Fork 204
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
compose: with existing infra #4541
base: main
Are you sure you want to change the base?
Conversation
78e4e1d
to
5dddd1f
Compare
This is an interesting idea, @weikanglim. I like having a sentinel file to help |
@ellismg We can pick a different name, like |
5dddd1f
to
8be2a88
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
|
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.
Some small feedback - like the direction we are heading!
the progress display shows the root deployment URL, then displays resources created as each deployment runs in the background.
Do you think we should show the deployment URL for the subsequent deployments as well? I could image a UX where we made it more apparently there were two ARM Deployments running sequentially. Do you think that's going too far? I'm personally wondering if it will be confusing that there are resources listed in the output here that you don't see in the deployment log in the portal, since they are coming from a separate deployment?
Between the "service level infrastructure" stuff, using IaC for container app deployments, and some of the other stuff we've talked about it does feel like we're going to be in a place where an app "deployment" is made up of multiple arm deployment operations. I'm wondering if we should lean into that and make it more apparent in the UX?
8be2a88
to
79c75cb
Compare
79c75cb
to
989e4f5
Compare
@ellismg Updated the UX, I do feel better about exposing the deployments here considering it's a backbone of the feature that is noteworthy. I also like where we're going here. I will work with our UX friends for a final pass once everyone is back. |
This change allows for composability to work with an existing
infra
directory unmanaged by azd.Infra provisioning. The provisioning engine has been updated to serially provision the root
./infra
, then./infra/azd
if it exists. The following behavioral changes have been applied:Composability synth. The synthesized infra directory has a
.azd
file to serve as a sentinel. If.azd
exists in a directory, i.e../infra/foo
, it means the directory./infra/foo
is "azd managed". This used to achieve the following behavior when runninginfra synth
:./infra/.azd
exists, we overwrite./infra
../infra/azd
.UX
Provision:
Destroy:
TBD