feat: route azure.yaml templates through Foundry adoption flow#8952
Conversation
Add TemplateTypeAzureYaml constant for unified azure.yaml templates that carry templateType=extension.ai.agent. Update EffectiveType() to detect these by checking both the source URL suffix and templateType. Replace the TemplateTypeAzd init case (which attempted git clone) with the Foundry adopt flow: download the azure.yaml content, resolve the agent name interactively, derive the project folder, and call runInitFromAzureYaml. Add TemplateTypeAzureYaml to sample_list known types and DTO mapping. Update unit tests with new EffectiveType cases. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
📋 Prioritization NoteThanks for the contribution! The linked issue isn't in the current milestone yet. |
There was a problem hiding this comment.
Pull request overview
This PR fixes a broken path in the azure.ai.agents extension's interactive init template picker. Previously, a unified azure.yaml template (source URL pointing at an azure.yaml blob, tagged templateType: extension.ai.agent) was classified as a full azd repo and git cloned, which failed because a blob URL isn't a cloneable repo. The PR introduces a distinct TemplateTypeAzureYaml classification and routes those templates through the existing Foundry adoption flow (runInitFromAzureYaml) instead.
Changes:
- Adds the
TemplateTypeAzureYamlconstant and extendsEffectiveType()to return it when the source ends inazure.yaml/azure.ymlandtemplateType == "extension.ai.agent". - Replaces the interactive picker's
TemplateTypeAzdswitch case with aTemplateTypeAzureYamlcase that downloads the manifest, resolves the agent name, derives the project folder, and callsrunInitFromAzureYaml. - Maps the new type to
ManifestURL+azd ai agent init -minsample_list.goand adds it to the known--typefilter values, plus 5 newEffectiveTypeunit test cases.
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_from_templates_helpers.go |
Adds TemplateTypeAzureYaml constant and the EffectiveType() branch (correctly gated on templateType). |
cli/azd/extensions/azure.ai.agents/internal/cmd/init.go |
Swaps the picker's TemplateTypeAzd case for a TemplateTypeAzureYaml adoption case — but this removes handling for full azd repo templates, which now fall through to the manifest flow. |
cli/azd/extensions/azure.ai.agents/internal/cmd/sample_list.go |
Registers the new type in knownSampleListTypes and DTO mapping; public doc comments/help still describe only agent/azd. |
cli/azd/extensions/azure.ai.agents/internal/cmd/init_from_templates_helpers_test.go |
Adds table-driven EffectiveType cases for the new type and its fallbacks. |
Key concern: the case TemplateTypeAzd: branch was removed rather than kept alongside the new case (contrary to the PR description), so templates classified as TemplateTypeAzd (repo slugs, still modeled in fixtures and sample_list.go) are now mis-routed to runInitFromManifest and will fail. The new azure.yaml DTO/type value also lacks the per-type test coverage and documentation the existing types have.
jongio
left a comment
There was a problem hiding this comment.
The new TemplateTypeAzureYaml routing logic is sound: EffectiveType() correctly requires both the extension.ai.agent discriminator and an azure.yaml/yml suffix, and the downstream calls to readManifestContentForInitDetection / resolveInitAgentName / runInitFromAzureYaml compose cleanly with the existing Foundry adoption flow.
One question on intent: the PR description states "The TemplateTypeAzd case (for full cloneable repo templates) is preserved unchanged," but the diff replaces it entirely with the new TemplateTypeAzureYaml case. Templates whose EffectiveType() still resolves to TemplateTypeAzd (repo-slug sources that don't end in any yaml) now fall through to default, which treats the source as an agent manifest pointer. Is dropping the azd init -t dispatch from the interactive picker intentional? If so, the description and fixtureTemplates() test fixture (which includes a TemplateTypeAzd entry) should be updated to reflect this.
Motivation
When the template picker selects a unified
azure.yamltemplate (one withtemplateType: "extension.ai.agent"whose source URL points to anazure.yamlfile), the previousTemplateTypeAzdcode path attempted togit clonethe source URL. This fails because the URL is a blob path inside a repository, not a cloneable repo.Approach
Introduce a new
TemplateTypeAzureYamlconstant to distinguish unified azure.yaml templates from full azd template repositories. Route these templates through the existing Foundry adoption flow (runInitFromAzureYaml) which correctly downloads the azure.yaml and its sibling files, stages them locally, and scaffolds the project.Key changes:
TemplateTypeAzureYaml-- keepsTemplateTypeAzdintact for actual azd repo templatesEffectiveType()-- returnsTemplateTypeAzureYamlwhen both the source ends withazure.yaml/azure.ymlANDtemplateType == "extension.ai.agent"TemplateTypeAzureYamlcase in init -- downloads content, resolves agent name viaresolveInitAgentName(interactive prompt or--agent-nameflag), derives the project folder, then callsrunInitFromAzureYamlsample_list.go-- added to known types and DTO mapping (usesManifestURL+azd ai agent init -mcommand)TestEffectiveTypecases covering the new type and fallback behaviorNotes
TemplateTypeAzdcase (for full cloneable repo templates) is preserved unchangedname:field -> template title -> interactive prompt