feat: adopt unified azure.yaml in azd ai agent init -m#8885
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the azd ai agent init -m <pointer> flow in the azure.ai.agents extension to detect when -m points at a sample’s unified Foundry azure.yaml and, in that case, adopt that manifest (and its sibling files) as the project’s root manifest via azd init -t, rather than generating a new project manifest from an agent manifest.
Changes:
- Adds unified-
azure.yamldetection (looksLikeFoundryAzureYaml) and a new adoption path (runInitFromAzureYaml) that stages local/remote sample directories and adopts them as the project template. - Refactors project scaffolding into shared helpers (
deriveEnvName,scaffoldProject) used by both the legacy manifest flow and the new adoption flow. - Adds unit tests for adoption helpers and documents the new behavior in the extension changelog.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| cli/azd/extensions/azure.ai.agents/internal/cmd/init.go | Routes -m pointers to adoption vs legacy manifest behavior, and refactors project scaffolding into shared helpers. |
| cli/azd/extensions/azure.ai.agents/internal/cmd/init_adopt.go | Implements unified azure.yaml detection, local/remote staging, and adoption via azd init -t. |
| cli/azd/extensions/azure.ai.agents/internal/cmd/init_adopt_test.go | Adds tests covering detection, naming/dir derivation, and local staging behavior. |
| cli/azd/extensions/azure.ai.agents/CHANGELOG.md | Adds a feature entry describing the new adoption behavior and its limitations. |
jongio
left a comment
There was a problem hiding this comment.
4 files changed (+722 -68). Clean refactor of ensureProject into reusable scaffoldProject/deriveEnvName, plus a new adoption path for unified azure.yaml manifests.
The detection logic (looksLikeFoundryAzureYaml) is solid and the routing between adoption vs generation is unambiguous. Test coverage on the new helpers is thorough.
A few items worth considering inline.
What
azd ai agent init -m <pointer>now accepts a sample's unified Foundryazure.yamlas an input. When the pointer resolves to a unified project manifest,initadopts thatazure.yamlas the new project's manifest instead of generating one from an agent manifest.Closes part of #8798 (fresh-project adoption). Existing-project merge is tracked separately in #8884.
Behavior
-m <azure.yaml>When
-mpoints to a unifiedazure.yaml/azure.yml:inittreats it as a complete project manifest when itsservices:contain Foundry hosts such asazure.ai.project,azure.ai.agent,azure.ai.connection, orazure.ai.toolbox.azure.yamlbecomes the project-rootazure.yaml.$reffiles, keep their sample-relative layout..azure/<env>.infra.provider: microsoft.foundry.Resulting shape:
This path does not generate agent services from an agent manifest, does not bury the sample's
azure.yamlundersrc/<agent>/, and does not duplicate Foundry resources that are already declared in the unified manifest.-m <agent.manifest.yaml>Existing behavior is preserved. The agent manifest remains a template input:
initresolves manifest parameters and prompts, then generates or updates the projectazure.yamlfrom that manifest.Scope
This PR covers fresh-project adoption. If the target directory already has
azure.yaml/azure.yml, adoption is refused with guidance instead of overwriting or merging. Merging a sample's services into an existing project is tracked in #8884.Tests
Added coverage for unified-manifest detection, local/GitHub staging behavior,
azure.ymlnormalization, target-directory conflict checks, and staging cleanup. Full agents-extension checks are passing.