Summary
Follow-up to #8798. The initial implementation (PR adopting a sample's unified azure.yaml via azd ai agent init -m) handles the fresh-project case: when the target directory has no azure.yaml, the sample's azure.yaml (and referenced files) is adopted as the project manifest via azd-core's native template adoption.
The existing-project case is not yet supported. When a project-root azure.yaml already exists and the user runs azd ai agent init -m <sample azure.yaml>, the command currently returns a clear, actionable error rather than merging.
Desired behavior
Fall back to today's "add to project" behavior: append the sample's agent service(s) (and any uses:-referenced azure.ai.project / azure.ai.connection / azure.ai.toolbox sibling services not already present) into the existing azure.yaml, copying each agent's project: source directory into the project. Resolve service-name collisions (reuse resolveCollisions), and skip siblings that already exist so dependencies still resolve.
Why it was split out
Correctly appending a unified azure.yaml's services into an existing project requires careful per-host service round-tripping through Project().AddService — e.g. uses: is carried in AdditionalProperties and wired separately in the manifest flow, and each Foundry host promotes a different set of fields. Getting this wrong can drop or duplicate keys in the written azure.yaml, and it's hard to verify without live gRPC. Splitting it keeps the primary fresh-project adoption shippable and well-tested.
Acceptance
azd ai agent init -m <sample azure.yaml> in a directory with an existing project azure.yaml appends the sample's agent service(s) + missing referenced siblings, copying source dirs, with collisions resolved.- The written
azure.yaml round-trips cleanly (no dropped/duplicated keys; uses: preserved).
- Tests cover the merge (including name collisions and already-present siblings).
Related
Summary
Follow-up to #8798. The initial implementation (PR adopting a sample's unified
azure.yamlviaazd ai agent init -m) handles the fresh-project case: when the target directory has noazure.yaml, the sample'sazure.yaml(and referenced files) is adopted as the project manifest via azd-core's native template adoption.The existing-project case is not yet supported. When a project-root
azure.yamlalready exists and the user runsazd ai agent init -m <sample azure.yaml>, the command currently returns a clear, actionable error rather than merging.Desired behavior
Fall back to today's "add to project" behavior: append the sample's agent service(s) (and any
uses:-referencedazure.ai.project/azure.ai.connection/azure.ai.toolboxsibling services not already present) into the existingazure.yaml, copying each agent'sproject:source directory into the project. Resolve service-name collisions (reuseresolveCollisions), and skip siblings that already exist so dependencies still resolve.Why it was split out
Correctly appending a unified
azure.yaml's services into an existing project requires careful per-host service round-tripping throughProject().AddService— e.g.uses:is carried inAdditionalPropertiesand wired separately in the manifest flow, and each Foundry host promotes a different set of fields. Getting this wrong can drop or duplicate keys in the writtenazure.yaml, and it's hard to verify without live gRPC. Splitting it keeps the primary fresh-project adoption shippable and well-tested.Acceptance
azd ai agent init -m <sample azure.yaml>in a directory with an existing projectazure.yamlappends the sample's agent service(s) + missing referenced siblings, copying source dirs, with collisions resolved.azure.yamlround-trips cleanly (no dropped/duplicated keys;uses:preserved).Related
-m <agent.manifest.yaml>.