The end state for all of this is that you can walk into a repo that has never heard of Azure, run azd up, and it works. azure.yaml becomes a file you write to override us, not a file you write to start.
This is mostly the payoff of the other work rather than a big lift of its own. Defaults come from a provider, detection tells us what the app is, external references mean the parts we can't detect can be pointed at instead of described. Once those land there isn't much left that azure.yaml is genuinely required for on day 0. What's left is that we refuse:
ERROR: no project exists; to create a new project, run `azd init`
So the change is that when there's no project, we infer one instead of refusing.
The gate on this, and I don't think we should ship any of it without settling this first, is determinism. The same repo has to produce the same deployment on my machine, on a colleague's machine, in CI, and after an azd upgrade. If what we infer moves with our version or with which extensions someone happens to have installed, we've built something that works right up until it doesn't, and then fails in about the least debuggable way available to us. "It deployed differently for me" is a terrible bug to receive.
The design question I'd want answered in this issue is whether inference writes anything down.
My lean is that it does, and that the first successful azd up materializes what it inferred into a real azure.yaml. It costs us a little of the magic, but the whole premise of "you write azure.yaml to override us" is that there's a file there to override. If we keep it purely in memory, we get a third state where the deployment exists and the description of it doesn't, and every question anyone asks after that point is hard to answer. Writing it also solves the CI reproducibility problem for free, because the second person to touch the repo gets the same file rather than re-running inference against a different environment.
We also need to say what we decided before we do anything expensive. azd up printing a full plan (services, resources, region, and where each of those came from) and a way to look at that without committing to it. Nobody should find out what we inferred by reading the resource group afterwards.
The end state for all of this is that you can walk into a repo that has never heard of Azure, run
azd up, and it works.azure.yamlbecomes a file you write to override us, not a file you write to start.This is mostly the payoff of the other work rather than a big lift of its own. Defaults come from a provider, detection tells us what the app is, external references mean the parts we can't detect can be pointed at instead of described. Once those land there isn't much left that
azure.yamlis genuinely required for on day 0. What's left is that we refuse:So the change is that when there's no project, we infer one instead of refusing.
The gate on this, and I don't think we should ship any of it without settling this first, is determinism. The same repo has to produce the same deployment on my machine, on a colleague's machine, in CI, and after an azd upgrade. If what we infer moves with our version or with which extensions someone happens to have installed, we've built something that works right up until it doesn't, and then fails in about the least debuggable way available to us. "It deployed differently for me" is a terrible bug to receive.
The design question I'd want answered in this issue is whether inference writes anything down.
My lean is that it does, and that the first successful
azd upmaterializes what it inferred into a realazure.yaml. It costs us a little of the magic, but the whole premise of "you writeazure.yamlto override us" is that there's a file there to override. If we keep it purely in memory, we get a third state where the deployment exists and the description of it doesn't, and every question anyone asks after that point is hard to answer. Writing it also solves the CI reproducibility problem for free, because the second person to touch the repo gets the same file rather than re-running inference against a different environment.We also need to say what we decided before we do anything expensive.
azd upprinting a full plan (services, resources, region, and where each of those came from) and a way to look at that without committing to it. Nobody should find out what we inferred by reading the resource group afterwards.