feat: carry Foundry agent and resource definitions in azure.yaml#8779
Merged
huimiu merged 55 commits intoJun 25, 2026
Conversation
…dry service target
Base automatically changed from
huimiu/foundry-unified-init
to
huimiu/foundry-azure-yaml
June 24, 2026 03:24
jongio
reviewed
Jun 24, 2026
jongio
left a comment
Member
There was a problem hiding this comment.
Solid architectural change. The decomposition of Foundry resources into individual azure.yaml service entries with uses: ordering is well-designed, and the fallback collectors (sibling service wins, bundled agent config is the legacy fallback) are cleanly implemented with good test coverage. A few observations below.
jongio
reviewed
Jun 24, 2026
jongio
left a comment
Member
There was a problem hiding this comment.
Incremental review (22 commits since last pass at 01463ff). CI is green, overall architecture is clean. The new pkg/foundry package is well-designed: proper cycle detection, depth bounds, error typing, and good test coverage. The resource-service split across per-host extensions is consistent and well-factored.
Prior unresolved items (4 comments from my earlier review remain open with no replies):
sanitizeServiceNameonly strips spaces (resource_services.go:193)- Path traversal in
resolveSkillInstructions(skills service_target.go:180) - Silent yaml.Marshal skip (agent_definition.go:348)
- Silent empty connName skip (resource_services.go:87)
I won't re-post these, but they still apply to the current HEAD.
New observations on the pkg/foundry package:
-
ExpandEnvsentinel restoration correctness (templating.go:68-70): The sentinel is guaranteed absent from the input, but env var expansion runs after masking. If an env var resolves to a string containing the sentinel prefix (azdFoundryTemplateSpan_0_),strings.Replacewill match it and inject a Foundry span where it doesn't belong. Extremely unlikely in practice, but the correctness invariant ("Foundry expressions are always returned byte-for-byte") is violated in that case. A simple fix: after expansion, verify each placeholder appears exactly once before replacing, or use a sentinel that encodes a random token per call. -
looksLikeInstructionsPathheuristic (includes.go:262-268): Inline prose that ends with.mdor.txt(e.g., "Follow the steps in README.md") will be incorrectly classified as a file path and rebased. The current check (single-line + suffix) is a reasonable heuristic, but consider also requiring a path separator or./prefix, or at least documenting the false-positive risk so authors of$ref'd files know to avoid ambiguous instructions values. -
Nil map-value guard (resource_services.go:222-229, 255-261, 287-293): The
collectProjectDeployments/collectConnections/collectToolboxescollectors iterate the services map and dereference each value's Host field. If a map ever contains a nil value (unlikely from azd core, but possible from test code or future refactors), this panics. A nil guard insortedServiceswould be cheap insurance.
All three are low-to-medium severity. The overall approach is solid; the design of ResolveFileRefs + YAMLDocument as a read/write pair sharing path logic is thoughtful. Ship it once the prior items are addressed.
jongio
reviewed
Jun 24, 2026
jongio
left a comment
Member
There was a problem hiding this comment.
Incremental review (1 commit since last pass at e59e938). The fix commit d6fd4da is clean and well-scoped:
-
Legacy host restored:
microsoft.foundryadded toFoundryServiceHostsfor backward compat. Tests cover mixed-host ambiguity detection. Schemarefcorrectly points to/main/...microsoft.foundry.json. -
Whitespace endpoint trimming:
strings.TrimSpaceapplied consistently infoundryServiceEndpoint,warnNetworkIgnoredInBrownfield, and the synthesizer's brownfield check. Blank endpoints now correctly trigger greenfield mode. Test added. -
Missing brownfield warning:
warnNetworkIgnoredInBrownfieldwas only called on the synthesizer path. Now also called on the on-disk Bicep path whenendpoint:is set. Good catch.
No concerns. CI is green for the core pipelines; agents-public build is still pending (expected timing). LGTM on this increment.
Collaborator
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
jongio
reviewed
Jun 24, 2026
jongio
left a comment
Member
There was a problem hiding this comment.
Incremental review (5 new commits since d6fd4da). All five address prior review feedback:
- Path traversal rejection in
resolveSkillInstructionsis correct: checks beforefilepath.Join, covers\and/separators, has test coverage for nested traversal (sub/../../escape.md). - Warnings for empty sanitized names are user-facing on stderr, consistent with
WarnLegacyAgentShape. - Schema docs now accurately reflect that remote URLs aren't supported.
azure.ai.*/schemas/*.jsonglob ensures cross-extension `` resolution works offline.- Marshal failure logging makes the validation skip visible during troubleshooting.
No new issues found in this increment.
trangevi
reviewed
Jun 25, 2026
| @@ -1,7 +1,7 @@ | |||
| // Copyright (c) Microsoft Corporation. All rights reserved. | |||
Member
There was a problem hiding this comment.
Why are these files moved into the top level azd pkg?
Member
There was a problem hiding this comment.
These files (the ref resolver, the azure.yaml edit helper, and the variable expander) were previously in azure.ai.agents/internal/project/. The problem: the connections, routines, and toolboxes extensions also need ref resolution and variable expansion for their own azure.yaml service entries. Keeping these in agents' internal package would force a circular dependency or require other extensions to import agents internals.
pkg/foundry is the shared-helpers layer accessible to all Foundry extensions without cross-extension coupling.
Member
Author
There was a problem hiding this comment.
These helpers (the $ref resolver, the edit helper, and the ${VAR} expander) used to live in agents'' internal/ package. Connections, routines, and toolboxes now need them too, and Go does not allow importing another extension''s internal/. pkg/foundry gives them one shared home instead of duplicated copies.
| // instead of service-level properties. Tracks migration of older Foundry | ||
| // projects off the legacy shape. | ||
| FoundryAgentLegacyConfigKey = AttributeKey{ | ||
| Key: attribute.Key("foundry.agent.legacy_config_shape"), |
Member
There was a problem hiding this comment.
What actually sets this? Is this something the azd folks are alright with being added to telemetry?
Member
There was a problem hiding this comment.
It's set in the project telemetry collection (cli/azd/cmd/actions.go area) when legacyAgentConfig is detected during project loading. The flag fires when a project still uses the deprecated config: block on its agent service entry instead of the new service-level properties introduced in this PR.
Classification is SystemMetadata / FeatureInsight, which is the standard azd tier for tracking feature-adoption signals (same tier as ProjectServiceHostsKey and ProjectServiceLanguagesKey). It doesn't capture user content, just a boolean indicating the project is on the old shape.
Member
Author
There was a problem hiding this comment.
Small correction: it is set in pkg/project/project.go during Load(), not actions.go. When a project loads with an azure.ai.agent service still using the old config: block, we tag a boolean. No user content, same tier as the existing ProjectServiceHostsKey.
| @@ -0,0 +1,496 @@ | |||
| // Copyright (c) Microsoft Corporation. All rights reserved. | |||
Member
There was a problem hiding this comment.
What is the plan to stop supporting old formats? Adding this file now gives at least a third place where we have agent objects defined, making it all that much more difficult to make sure things are being updated in the right places. Would be good if we have an in place plan to switch completely and remove all of the extra logic
Member
Author
There was a problem hiding this comment.
The upcoming release will continue to support the old formats. We can consider deprecating them in the following version
| @@ -1,6 +1,6 @@ | |||
| { | |||
Member
There was a problem hiding this comment.
Why do we need both these files, and the individual schemas in the other extensions?
Member
There was a problem hiding this comment.
The agents extension bundles peer-extension schemas (Connection.json, Toolbox.json, etc.) so that $ + ref resolution in agent definitions can validate those shapes offline without requiring the connections/toolboxes/skills extensions to be installed at validation time.
The individual extension schemas (e.g., in azure.ai.connections/schemas/) remain the canonical source. These copies in azure.ai.agents/schemas/ are resolved via the azure.ai.*/schemas/*.json glob at build time, enabling cross-extension validation within a single extension's scope.
Member
Author
There was a problem hiding this comment.
They are two different shapes. agents/schemas/Connection.json is a nested item inside the legacy microsoft.foundry host (one entry composing arrays). azure.ai.connections/.../azure.ai.connection.json is the new host: azure.ai.connection service, where each connection is its own service. Both exist because this PR keeps the legacy host working alongside the new per resource hosts. They are not copies; the shapes differ.
github-actions Bot
added a commit
that referenced
this pull request
Jun 29, 2026
Four recurring themes promoted from PR reviews merged since 2026-06-22: 1. go.instructions.md: Test goroutine safety — t.Fatal/require.NoError must not be called from httptest handler goroutines or other non-test goroutines; HTTP headers must be set before WriteHeader. (Source: #8790) 2. extensions.instructions.md: Duplicate helper detection — export shared helpers from the owning package instead of copying function bodies across extension packages. (Source: #8794, #8809) 3. extensions.instructions.md: User-provided path validation — paths from azure.yaml fields (instructions, entryPoint, etc.) must be validated to stay within the expected root directory. (Source: #8779, #8599) 4. extensions.instructions.md: Cross-extension test isolation — tests loading sibling-extension files must skip when absent; extension functional tests should have dedicated CODEOWNERS entries. (Source: #8809, #8754) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
trangevi
added a commit
that referenced
this pull request
Jun 29, 2026
…and IaC-less init (#8818) * feat(agents): add microsoft.foundry azure.yaml schema (#8603) * feat(agents): add microsoft.foundry azure.yaml schema Schema-only scaffolding for unifying Microsoft Foundry agent config in azure.yaml (design spec PR #8590, section 2.3). - Add the host: microsoft.foundry conditional to schemas/v1.0 and schemas/alpha azure.yaml.json, composing the extension schema at the service level via allOf and turning off project/runtime/docker/image/config. - Add microsoft.foundry to the host examples list. - Publish the Foundry extension schemas under cli/azd/extensions/azure.ai.agents/schemas/: microsoft.foundry.json plus per-resource files (Agent, Skill, Routine, Connection, Toolbox, Deployment, FileRef), ported from the PM preview repo with $id rewritten to the azure-dev path and relative $refs preserved. - microsoft.foundry.json uses additionalProperties: true at the project level (deliberate deviation from the preview's false) so future Foundry resource types do not break the schema, per the brief and design spec section 2.3. Authoring-only: no service-target wiring, provider registration, or alpha-feature gating (those are later PRs). * fix(agents): relax PromptAgent to accept skill without instructions PromptAgent now requires name + kind plus at least one of instructions or skill (anyOf), instead of always requiring instructions. A prompt agent backed by a skill (which supplies the instructions) no longer fails schema validation. This fixes the complex sample's summarizer-agent validation failure. * fix(agents): enforce Foundry schema dependencies Require project when hosted agents define docker or runtime settings, and enforce routine trigger-specific required fields for schedule, webhook, and event triggers. * fix(agents): align Foundry schema constraints Use conditional schema constraints for hosted-agent project requirements and routine trigger-specific fields. * feat: target foundry azure.yaml schema at integration branch with validatable samples * fix: normalize foundry azure.yaml schema URLs to short raw.githubusercontent form * feat(agents): resolve $ref file includes with overlay overrides in Foundry config (#8627) * feat: resolve $ref file includes with overlay overrides in Foundry agents config * fix: modernize $ref cycle check with slices and trim whitespace in include paths * feat(agents): add --image flag to agent init command (#8689) * feat(agents): add --image flag to agent init command Add --image flag to `azd ai agent init` to allow users to specify a pre-built container image directly during init. When provided: - Writes the image URL to the `image` field in agent.yaml - Skips ACR connection prompts (user manages their own registry) - Validates the image URL contains registry/image format - Returns error if combined with --deploy-mode code This enables non-interactive init workflows for VNet scenarios where users bring their own private ACR with pre-built images. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * feat(agents): short-circuit template/language selection when --image is set When --image is provided without --manifest, synthesize a minimal hosted container manifest and route through the manifest flow, skipping the init-mode/template/language prompts and code scaffolding (a pre-built image has no source to scaffold). Requires --agent-name; validates the image early before any project/template init. The image is written to agent.yaml and ACR is skipped via the existing --image handling. * fix(agents): skip ACR connection prompt for --image in interactive mode The interactive ACR connection discovery/prompt (configureAcrConnection via configureFoundryProjectEnv) was gated on a.isCodeDeploy, which is false for a pre-built --image (container deploy). Pass a.skipACR() to the four selectFoundryProject call sites so an image-based hosted agent skips ACR setup in interactive mode too, matching the AZD_AGENT_SKIP_ACR env behavior. The hosted-agent region filter now also applies to --image, which is correct since it runs as a hosted agent. * fix(agents): skip startup-command prompt for pre-built image agents A pre-built container image runs its own entrypoint, so no startup command applies. Skip resolveStartupCommandForInit when the agent template references a pre-built image (agentUsesPreBuiltImage), covering both --image (synthesized manifest) and a -m manifest that already specifies an image. Without this, the container-deploy path prompted "Enter the command to start your agent" because the image src dir has no main.py to auto-detect. * fix(agents): persist AZD_AGENT_SKIP_ACR in the no-model-resources path configureModelChoice only wrote AZD_AGENT_SKIP_ACR in the deferred-headless and main model-config paths. A completing no-model-resources flow (e.g. a pre-built --image agent selected interactively) returned without setting it, so provision would still create an ACR despite --image. Set it via skipACR() before returning, matching the other two call sites. * fix(agents): make --image deployments use the pre-built image end-to-end Real init/provision/deploy validation showed that --image init correctly wrote image: and AZD_AGENT_SKIP_ACR=true, but deploy still defaulted to the Dockerfile build path in --no-prompt mode. Treat AZD_AGENT_SKIP_ACR=true as an explicit BYO-image signal for hosted container agents so Package returns a remote pre-built image artifact and Publish is skipped. The same E2E also found the synthesized manifest used responses protocol version v1, while invoke requires 1.0.0. Generate 1.0.0 for --image manifests. * fix(agents): tighten --image reference validation Replace the slash-only validation with a stricter fully-qualified image reference regex that requires an explicit registry host, repository path, and optional tag or sha256 digest. Add coverage for digest, localhost/port registry, and malformed refs such as URL schemes, namespace-only refs, missing repository, short digest, and uppercase repository names. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * feat(agents): bicep-less init for azd ai agent init (#8643) * feat(agents): bicep-less init for azd ai agent init `azd ai agent init` now produces a project without an on-disk `infra/` directory and stamps `infra.provider: microsoft.foundry` on azure.yaml so provisioning is routed to this extension's provider. Init UX changes: - After the starter scaffold, the `infra/` tree is removed. - `azure.yaml` gets `infra.provider: microsoft.foundry` written and `infra.path: ./infra` removed. - ACR and Application Insights connection prompts are skipped during init; the extension's provisioning provider owns those resources. - The "no infra/ directory" warning for existing projects is suppressed when the provider is already declared. Core changes: - Relax the `infra.provider` JSON Schema (v1.0 and alpha) from a fixed enum to `pattern: "^[a-z0-9.]+$"` + `examples`, keeping typo catching while allowing extension-registered providers. New code: - internal/project/provisioning_provider.go: `FoundryProviderName` constant, single source of truth. - internal/cmd/init.go: `writeFoundryProvider`, `hasFoundryProviderDeclared` helpers. - internal/cmd/init_foundry_resources_helpers.go: `bicepless` parameter on `configureFoundryProjectEnv` and `selectFoundryProject` that short-circuits connection discovery. Tests: - TestHasFoundryProviderDeclared covers the warning-suppression predicate. - TestConfigureFoundryProjectEnv_BicepLessShortCircuits verifies the short-circuit fires before any Foundry data-plane call (uses a nil credential to make a regression crash loudly). * feat(agents): microsoft.foundry provisioning provider Adds an in-memory Bicep synthesizer and a provisioning provider that implements the full azdext provisioning gRPC surface for projects declaring `infra.provider: microsoft.foundry`. The provider generates, compiles, and deploys an ARM template on demand without writing Bicep to disk. Synthesizer (internal/synthesis): - Embeds the templates/main.bicep + modules/acr.bicep and the precompiled main.arm.json via `go embed`. - `Synthesize(Input)` returns the parameterized ARM JSON plus a manifest describing the synthesized resources. - `AcceptedHosts` input controls which agent host kinds the synthesizer will materialize (currently `azure.ai.agent`). Provider (internal/project): - `FoundryProvisioningProvider` implements all 9 azdext provisioning methods (Initialize, State, Deploy, Destroy, Preview, Parameters, Outputs, Resources, GetDeployment). - `ensureResourceGroup` creates the RG on demand. - Synthesizes from agent.yaml + host shapes, threads outputs back through the env, surfaces typed errors via exterrors. Service-target integration: - `AgentServiceTargetProvider.Initialize` is split into a cheap stub and lazy `ensureDeployContext` / `ensureEnv` calls so registration no longer requires a deploy context. - All 5 deploy-time entry points (Package, Publish, Deploy, Endpoints, GetTargetResource) gate on the lazy helpers. Registration: - `extension.yaml` declares the `provisioning-provider` capability with `microsoft.foundry`. - `internal/cmd/listen.go` registers `WithProvisioningProvider(FoundryProviderName, ...)`. Errors: - `internal/exterrors/codes.go` adds provisioning op names and error codes used by the provider. * feat(agents): add `--infra` eject flag to `azd ai agent init` Implements the bicepless-foundry spec's eject command: `azd ai agent init --infra` writes the synthesized Bicep templates from azure.yaml to ./infra/ on disk. Behavior follows RFC #8065 and the spec (spec/bicepless-foundry/spec.md §Eject Command): | Trigger | Behavior | | --------------------------------------------- | ------------------------------------------------------------------------------------------- | | empty dir + --infra | Run normal init flow, then write ./infra/ | | existing foundry project, no ./infra/, --infra | Standalone eject: write ./infra/; no init prompts, no agent-code change, azure.yaml unmutated | | ./infra/ already exists + --infra | Refuse with CodeInfraEjectExists, suggest delete + retry | | not an azd agent project + --infra | Refuse with CodeInfraEjectNoFoundryService | New code: - internal/cmd/init_infra.go: `ejectInfra` walks `synthesis.TemplatesFS()` to ./infra/, writes `main.parameters.json` from the synthesizer's parameter map, and prints the spec's success block. Atomic cleanup of partial writes on error. - internal/cmd/init.go: `--infra` flag plus top-of-RunE short-circuit for the standalone-eject case and a post-init hook for the empty-dir case. The standalone branch validates that no init-driving inputs (-m, --src, positional arg) were also passed; honoring them would silently drop the user's argument. The post-init chain skips silently when init returned without producing a foundry service so the user never sees "nothing to eject" after init succeeded. Provider lifecycle hardening (reviewer findings, all critical/major): - `FoundryProvisioningProvider.Initialize` is now cheap: tenant lookup and credential construction moved into a lazy `ensureCredential` helper called on-demand by `deploymentsClient` / `ensureResourceGroup`. azd-core may call Initialize on providers it never deploys with (env refresh, multi-provider projects); making it cheap avoids needless RPCs and lets metadata-only calls (Parameters, PlannedOutputs) succeed without auth. - `Destroy` no longer silently leaks resources. With `Force=true` it deletes the entire resource group (the previous behavior only removed the deployment record). Without `--force` it returns a structured `CodeDestroyRequiresForce` naming the RG and pointing at `azd down --force`. - `armOutputsToProto` and `armInputsToProto` JSON-encode non-string values via a shared `encodeParamValue` helper. Prior behavior collapsed arrays/objects via Go's default %v formatter (`["a","b"]` -> `[a b]`) which is unparseable downstream. - `Parameters` and `armParameters` are nil-safe on `synthResult` so a programming error elsewhere returns a structured Internal error instead of panicking. - `Preview` returns `Compatibility` (feature not implemented in this version) instead of `Validation`; the user supplied no invalid input. - `findFoundryService` and its eject equivalent return `Dependency` instead of `Validation` for missing-service errors; a missing service is a missing dependency, not malformed input. Multiple-services error split into its own `CodeInfraEjectMultipleFoundryServices` so telemetry can differentiate "none" from "too many". Tests (all passing under `go test ./... -short`): - `init_infra_test.go`: 10 test cases covering refusals (azure.yaml missing, ./infra/ exists, ./infra/ is a file, no foundry service, multiple foundry services, conflicting args with -m/--src/positional) and happy paths (file shape, parameters shape, no-docker omits ACR param). - `foundry_provisioning_provider_test.go`: `TestEncodeParamValue` (10 sub-cases for the JSON-encode helper), `TestArmOutputsToProto_JSONEncodesNonStrings`, `TestArmInputsToProto_JSONEncodesNonStrings`, `TestParameters_NilSafeOnMissingSynthResult`, `TestArmParameters_NilSafeOnMissingSynthResult`, `TestDestroy_RefusesWithoutForce`, `TestFindFoundryService_DependencyCategory`, `TestPreview_NotImplemented` updated to assert `Compatibility` category. End-to-end verified via `azd x build` + manual smoke tests against the installed extension: standalone eject succeeds, three conflicting- args combinations refuse cleanly with the structured error, refuse- when-./infra/-exists and refuse-when-multiple-services produce the expected output. Deliberate spec deviations (documented elsewhere, deferred): - Spec example lists `infra/modules/foundry-project.bicep`; our `main.bicep` is monolithic so the eject writes only the modules that actually exist (`main.bicep`, `modules/acr.bicep`, `abbreviations.json`, `main.parameters.json`). - Spec uses `--force` to overwrite an existing ./infra/; we follow the spec's later guidance to ask the user to delete and re-run. - Provider's on-disk reuse path (`Deploy` reads ./infra/main.bicep when present) is not implemented; the provider always uses the embedded ARM JSON. `--infra` is therefore inspection-only today; edits to the ejected `main.bicep` are not honored on the next `azd provision`. Tracked as separate work. - Telemetry fields `init.infra_flag` and `provision.synthesis_source` not yet emitted. * feat(agents): on-disk Bicep path + Preview via ARM what-if Adds support for projects that have an on-disk `./infra/` directory (typically the output of `azd ai agent init --infra`), and implements the provisioning Preview operation via ARM what-if for both inline and on-disk paths. On-disk path: - internal/project/ondisk_template.go detects `./infra/main.bicep`, compiles it via the bicep CLI, and feeds the resulting ARM JSON through the same deploy + outputs pipeline as the inline path. - `Parameters()` returns host-derived values regardless of source. Preview: - internal/project/preview_helpers.go renders an ARM what-if change summary (Create / Modify / Delete / NoChange / Ignore). - `Preview()` calls `ensureResourceGroup` first so what-if has a scope to query against. Robustness: - preprovision tolerates a missing agent.yaml on the inline-agents path (the synthesizer can still run from host shapes alone). - Deployment output names are canonicalized case-insensitively so ARM output lookups survive casing drift in the template. * chore(agents): polish: lint, drop starter clone, RG fix, comment trim Cross-cutting cleanup pass after the provider feature stabilized. - Satisfy golangci-lint and cspell on the bicepless feature. - Drop the `Azure-Samples/azd-ai-starter-basic` clone from init. `azd ai agent init` now invokes `azd init -t <emptyStagedDir> <targetDir>` to scaffold the project shape directly. Net -474 LoC. - Ensure the resource group exists before ARM what-if runs in Preview. - Trim verbose design-commentary from the bicepless code; comments now describe what code does and why, not the historical rationale. * fix(agents): purge soft-deleted Cognitive Services accounts on `azd down --force --purge` Foundry's CognitiveServices (AIServices) accounts soft-delete on RG removal and reserve the name for ~48h. The provider previously ignored options.GetPurge(), so the next `azd provision` failed with InvalidTemplateDeployment / FlagMustBeSetForRestore. Destroy now mirrors azd-core's built-in bicep provider purge flow: enumerate live accounts in the RG before BeginDelete (capturing name + location), delete the RG (soft-deleting the accounts), then purge each via DeletedAccountsClient.BeginPurge. - Hard-fails on purge / enumeration errors (silent skip would just reproduce the same bug on the next provision). - Skips the purge path when the RG is already gone at Destroy time (idempotent re-run). Documented in the Destroy docstring; users with a leftover from a prior incomplete cleanup can purge it manually via `az cognitiveservices account purge`. - Without --purge, the account remains soft-deleted (auto-expires per Azure retention) - unchanged behavior from prior commits. New OpCognitiveAccountList / OpCognitiveAccountPurge op-names give telemetry a way to distinguish the enumeration vs the purge step. Extracts collectPurgeableAccounts as a pure helper for unit testing; the SDK pager + poller calls stay inline in Destroy (consistent with the rest of the provider's untestable Azure SDK call sites). * fix(agents): address PR review feedback on bicepless feature - foundry_provisioning_provider.go: thread the caller's context into envValues so the Environment().GetValues gRPC call honors cancellation/timeouts instead of using context.Background(). - init_infra.go: correct the ejectInfra doc comment; it claimed infra.provider "stays azure.ai.agents" but the provider is microsoft.foundry. Now states the declared provider is left unchanged. - init.go: the missing-infra warning pointed users at running `azd ai agent init` in an empty directory, which no longer produces an infra/ directory now that init is bicep-less. Point to `azd ai agent init --infra` instead. * feat(provisioning): use subscription-scoped template for preview parity Switch to subscription-scoped ARM deployment so `azd provision --preview` runs what-if without pre-creating the resource group. The RG now appears in the what-if output as a Create operation, matching built-in bicep provider behavior. * feat(provisioning): render extension preview changes and stream progress Add a structured changes list to the provisioning preview proto and map it into the core preview renderer so `azd provision --preview` shows a colored resource diff for extension providers (previously only a string summary was sent and dropped). Route Deploy/Preview/Destroy progress to the console spinner via an injected console instead of debug-only logs, finishing the existing TODOs. * fix(agents): emit preview changes, clean up model deployments on down, fix ACR connection Preview now returns structured what-if changes so the core renderer shows a colored resource diff. Destroy deletes model deployments before the resource group so the Cognitive Services account delete no longer rolls back with CannotDeleteAccountWithDeployments. The ACR project connection uses the project identity client id plus the 2025-04-01-preview api-version, matching a working Foundry hosted-agent connection (fixes empty-credential and MissingApiVersionParameter failures). Includes a temporary go.mod replace pointing at the in-tree azd core; the core proto change must land and be published before this merges. * feat(agents): support Terraform as an IaC option for azd ai agent (#8756) * feat(agents): support Terraform as an IaC option for azd ai agent init Add `--infra=terraform` to `azd ai agent init` so it ejects a Terraform module (azurerm + azapi) to ./infra/ instead of Bicep, provisioning the same resources and emitting the same output contract, then stamps `infra.provider: terraform` so azd-core's built-in Terraform provider handles provisioning. Bicep paths are unchanged. - `--infra` flag changed from bool to string with NoOptDefVal=bicep: bare `--infra` ejects Bicep, `--infra=terraform` ejects Terraform, `--infra=bicep` is explicit, absent stays bicepless default. - Embed templates/terraform/*.tf; generate main.tfvars.json at eject time. - Terraform path stamps infra.provider: terraform in azure.yaml (the one place eject mutates it); Bicep path leaves azure.yaml untouched. - foundry_project_name defaults to env-name derivation when AZURE_AI_PROJECT_NAME is unset, mirroring the Bicep provider's sanitizeFoundryName. Refs #8705 * feat(agents): omit acr.tf and ACR outputs when no agent uses docker On the Terraform eject path, only emit ACR when at least one agent declares a docker: block: - acr.tf is written only in the docker case (it owns container_registry_name); main.tf has no ACR references otherwise. - outputs.tf is rendered from outputs.tf.tmpl (text/template) and includes the three AZURE_CONTAINER_REGISTRY_* / ACR connection outputs only when acr.tf is present, omitting them entirely otherwise (Terraform resolves resource references statically, so they cannot reference absent resources). - include_acr is no longer a module variable or a main.tfvars.json key -- the presence of acr.tf is the include-ACR decision. - main.tf also derives resource_group_name as rg-{env} and the project name from environment_name when those env vars are unset, so the bicepless-default -> Terraform flow provisions without extra setup. - Trimmed the ejected .tf comments to drop azd-internal references. Accepts asymmetry with the Bicep path (which always emits acr.bicep). Refs #8705 * docs(agents): fix misleading tfvars comment in writeTfvarsFile The comment claimed an 'ordered slice of lines' but the code uses a map[string]any. json.MarshalIndent sorts map keys, so the generated main.tfvars.json is deterministic; the comment now says so. Addresses a Copilot review note on PR #8756. The two other Copilot notes (replace() regex on main.tf:33, coalesce() empty-string fallback on main.tf:12) are false positives: Terraform's replace() treats a /.../-wrapped substring as a regex, and coalesce() skips empty strings, both verified against the HashiCorp docs and a live azd provision --preview. * feat(agents): secure-by-default private networking via azure.yaml (#8708) * feat(agents): private networking for host: microsoft.foundry Add a declarative network: block to the Foundry service in azure.yaml and teach the bicep-less synthesizer to provision a VNet-bound (network-secured) account from it. Additive: an absent block yields today's public account. - schema: network: surface (mode byo|managed, byo vnet/subnets tri-state, managed isolationMode, dns create-or-reference) on microsoft.foundry.json - synthesizer: decode network:, resolve ${VAR}, validate (mode coherence, vnet ARM id, subnet tri-state/CIDR, DNS rg/sub), emit network params + NetworkMode for telemetry - templates: new modules/network.bicep, subnet.bicep, private-endpoint-dns.bicep; resources.bicep/main.bicep guard the network path on enableNetworkIsolation (publicNetworkAccess Disabled, networkAcls Deny, agent networkInjections, account private endpoint + 3 AI DNS zones); main.arm.json regenerated - provider: pass azd env for ${VAR} resolution, emit provision.network_mode, warn that network: is ignored when endpoint: (brownfield) is set - docs/tests: synthesizer network tests, eject module assertions, extension README network section, telemetry-data.md provision.network_mode * fix(agents): preserve network ${VAR} refs through eject The existing on-disk provision flow resolves ${VAR} in main.parameters.json from the azd environment at provision time. Eject must therefore keep ${VAR} references verbatim instead of resolving them eagerly from the process env and freezing a literal into the ejected file. - synthesis.Input gains PreserveVarRefs; when set, byo.vnet.id and dns.subscription pass through verbatim and the format checks that cannot run on an unexpanded placeholder are skipped (concrete-but-malformed still fails) - eject (init --infra) sets PreserveVarRefs so the ejected main.parameters.json stays environment-portable; the provision path still resolves and validates - tests: synthesizer preserve-mode (pass-through + concrete validation) and an eject e2e asserting ${AZURE_VNET_ID}/${AZURE_DNS_SUBSCRIPTION_ID} survive * test(agents): add Foundry private-networking E2E harness Bash E2E harness validating host: microsoft.foundry private networking, designed to minimize Azure resource-operation time: - ONE real network account is provisioned (create+own matrix cell) with a BYO --image agent, then deploy + invoke prove the agent works under the VNet. - Scenario 1 (bicep-less) and the other 3 matrix cells (subnet create/reference x DNS own/reference) are verified with 'azd provision --preview' (ARM what-if), which creates nothing. - Scenario 2 (eject) is verified against the live account: eject -> what-if reports no changes (idempotent), proving the on-disk template + provision-time ${VAR} resolution reproduces the in-memory topology; a manual infra/ edit then surfaces as the only delta. Guards the ${VAR}-preservation fix end-to-end. - A shared BYO VNet (+ reference subnets / external DNS zones) is created once and reused across cells. Files: run-network-e2e.sh (phases 0-6 orchestrator), assert-resources.sh (live az topology checks: publicNetworkAccess Disabled, account PE groupIds, 3 AI DNS zones, agent-subnet delegation), lib.sh (logging/assert/azure.yaml mutation), README.md (cost rationale, prerequisites, cleanup). Westus account region per requirement; AcrPull granted to the project MI on the ABAC registry. * test(agents): run network E2E phases 0-4 without --image Decouple the private-networking E2E from the BYO-image init UX (PR 8689) so it runs against the current branch today: - Replace 'azd ai agent init --image' with a hand-authored azure.yaml fixture (foundry service + network: block + agent image:), created via 'azd env new'. image: yields includeAcr=false, matching BYO image, so no ACR at provision. Verified the fixture synthesizes: mode=byo, enableNetworkIsolation=true, includeAcr=false, ${VAR} resolved. - Gate phase 5 (deploy + invoke) behind RUN_DEPLOY=true: the headless BYO-image deploy needs the AZD_AGENT_SKIP_ACR short-circuit from PR 8689, otherwise deploy defaults to build and fails. Phases 0-4 (local gates, shared VNet, what-if matrix, one real provision, eject idempotency) validate all the networking code without it. - Fix the ABAC registry role: grant 'Container Registry Repository Reader' (ABAC-aware) instead of AcrPull; move the grant into the gated deploy phase. - Drop the --image preflight; README updated (scenario table, prerequisites, RUN_DEPLOY usage, role). * fix(agents): correct network bicep preflight + network-mode output casing Two product bugs surfaced by live E2E provisioning (ARM what-if does not catch either; both require a real deployment): 1. networkInjections preflight failure. The account and the network module deploy in the same template, so subnetArmId: network!.outputs.agentSubnetId compiled to an unresolved reference() at the CognitiveServices RP preflight, which then failed to convert networkInjections to its typed contract (InvalidResourceProperties). Build the subnet ARM id as a deterministic string from the concrete vnetId param instead, and add an explicit dependsOn so the subnet still exists before injection. Recompiled main.arm.json. 2. AZURE_FOUNDRY_NETWORK_MODE missing from canonicalOutputNames. ARM mangles output-name casing (AZURE_..._MODE -> azurE_..._MODE); without the canonical remapping the env key was stored mis-cased and azd env get-value AZURE_FOUNDRY_NETWORK_MODE returned empty. Added it to the restore list and a regression case to TestArmOutputsToProto_RepairsMangledKeyCase. Validated end-to-end: real westus network-isolated Foundry account provisions green with all topology assertions passing (publicNetworkAccess Disabled, networkAcls Deny, private endpoint, agent-subnet delegation, 3 AI DNS zones, network mode byo), across the full subnet create/reference x DNS own/reference matrix, plus eject idempotency (what-if reports no changes). * test(agents): make network E2E harness run green end-to-end Fixes found while running the harness against live Azure (phases 0-4): - Hand-authored project must include an agent.yaml (kind: hosted + image:) alongside azure.yaml; the foundry provider requires an agent definition file. - setup_project now sets AZURE_RESOURCE_GROUP (the subscription-scoped template creates the RG but the provider needs the name) and AZD_AGENT_SKIP_ACR=true (BYO-image deploy signal). - Phase 0 refreshes the dev extension from current source (build -> pack -> publish -> install) so the run tests local code, registering the provisioning-provider capability + microsoft.foundry provider. Gated by SKIP_EXT_REFRESH. - What-if matrix gates on a successful ARM what-if (exit 0) rather than grepping a summary-only preview; this still validates reference-mode subnet/zone existence and delegation against the real VNet. - Idempotent private-dns zone creation (reruns no longer fail on existing zones). - Add MAX_PHASE to stop early while iterating. - ACR grant uses the ABAC-aware Container Registry Repository Reader role. - Fix set -u unbound-variable crash in the phase-4 assert message. - .gitignore the transient per-run log directories. Phases 0-4 (local gates, shared VNet, what-if matrix, one real provision + topology assertions, eject idempotency) pass green. Phase 5 (deploy + invoke) stays gated behind RUN_DEPLOY=true and needs a reachable BYO agent image. * test(agents): build phase-5 image in ABAC-enabled ACR Update the Foundry private-network E2E harness so phase 5 can build the ~/agents/echo-dual image itself instead of requiring a prebuilt external image. - Add BUILD_IMAGE=true, ECHO_DUAL_DIR, ACR_NAME/ACR_RG, IMAGE_REPO/IMAGE_TAG. - Create the target ACR with --role-assignment-mode rbac-abac and reject reuse of non-ABAC registries. - Grant the caller Container Registry Repository Writer before the ACR Task push. Resolve the caller object id from the ARM token oid claim to avoid Microsoft Graph / Conditional Access failures. - Build with the required `az acr build --source-acr-auth-id [caller]` form. - Keep the project MI grant on the ABAC-aware Container Registry Repository Reader role for image pull. - Add TARGET_RG support so investigation runs can keep VNet, DNS, ACR, and the real Foundry env in a single RG. Live validation: the harness created an ABAC ACR, granted caller writer, built and pushed ~/agents/echo-dual with --source-acr-auth-id [caller], provisioned a private-networked Foundry account, and granted the project MI Repository Reader. The subsequent deploy failed from this public runner with the expected private endpoint 403, which is documented. * test(agents): grant private ACR pull to Foundry project identity Live phase-5 validation showed hosted-agent image pull uses the Foundry project managed identity, not the parent account identity. Update the network E2E harness to resolve AZURE_AI_PROJECT_ID via ARM and grant the project MI the ABAC-aware Container Registry Repository Reader role on the BYO ACR, falling back to the account MI only for older API shapes. Also persist AZURE_TENANT_ID in the azd env so postdeploy hooks do not fail on VM/managed-identity runners after deploy succeeds. * docs(agents): add BYO image VNet cheatsheet Add a concise README cheatsheet for initializing, provisioning, deploying, and invoking a hosted Foundry agent with a BYO container image under VNet private networking. Include ACR requirements for ABAC and private-only registries. * docs(agents): move private networking guide to docs Keep the extension README concise by moving the detailed Foundry private networking schema, requirements, and BYO-image VNet cheatsheet into `docs/private-networking.md`, with a short README pointer. * fix(agents): surface managed-network isolation output Live managed-network provisioning showed that the resources module emitted AZURE_FOUNDRY_MANAGED_ISOLATION_MODE but the subscription-scoped main template never forwarded it, so azd env only received AZURE_FOUNDRY_NETWORK_MODE. Forward the output from main.bicep, add it to the provider canonical output-name restore list, and cover ARM casing repair with a regression test. Also document the managed VNet provisioning scenario in the private-networking guide. Live validation: provisioned network.mode=managed in westus and verified the account had publicNetworkAccess Disabled, networkAcls Deny, networkInjections with useMicrosoftManagedNetwork=true, AZURE_FOUNDRY_NETWORK_MODE=managed, and AZURE_FOUNDRY_MANAGED_ISOLATION_MODE=AllowInternetOutbound. * fix(agents): keep managed-network data plane reachable Live managed-network deploy validation showed that managed mode configures the hosted-agent runtime to use a Microsoft-managed network but does not create a customer private endpoint for the Foundry data plane. Disabling public access in that mode makes azd deploy/invoke fail with `403 Public access is disabled`. Keep public data-plane access enabled for managed mode while preserving BYO mode behavior (public access disabled + private endpoint). Update the private networking guide with managed deploy/invoke guidance. Live validation: provisioned managed mode, converted the test ACR to ABAC, built the echo-dual image with `az acr build --source-acr-auth-id [caller]`, granted the Foundry project MI `Container Registry Repository Reader`, deployed successfully, and invoked the hosted agent successfully. * feat(agents): secure-by-default private networking for Foundry services Realign the azure.yaml `network:` surface to the natural Azure resource shape and make a network-bound Foundry account private in every mode. Reverses the prior managed-mode regression that flipped the account's publicNetworkAccess back to Enabled. Service sample 18 confirms managed mode supports a private data plane (customer private endpoint + the Microsoft-managed egress network), so declaring `network:` now always disables public data-plane access. Config: flat `network:` block with two orthogonal axes, no `mode` enum. - peSubnet (required) -> account private endpoint; omitting it while `network:` is declared is an error, never a silent public fallback. - agentSubnet (optional) -> present injects the agent into a customer subnet (BYO egress); absent uses the Microsoft-managed network (managed egress), where isolationMode becomes valid. Synthesizer/templates: - derive egress from agentSubnet presence (useManagedEgress); replace the networkMode param with a useManagedEgress bool. - disablePublicDataPlaneAccess = enableNetworkIsolation (always private). - add a managedNetworks/default child resource carrying isolationMode for managed egress. - validate peSubnet-required, isolationMode-managed-only, and single-VNet. Docs/tests/e2e: - rewrite docs/private-networking.md (host: azure.ai.agent, the value the provision provider actually accepts on this branch). - add synthesizer unit tests + a compiled-ARM regression guard. - add a live E2E harness (8-cell what-if matrix, BYO + managed-iso real provisions, eject idempotency) with an automatic jumpbox SOCKS tunnel so deploy/invoke can reach the private data plane; assert real account network-injection state rather than azd's echoed output. * docs(agents): use 'azd ai agent init --image' and assert real state in private-networking cheatsheet Managed-egress cheatsheet now scaffolds the agent via 'azd ai agent init --image' (writes agent.yaml) instead of assuming a hand-authored manifest, matching the BYO cheatsheet. Replace the env-output 'Expected outputs' block (azd echoing its own AZURE_FOUNDRY_* classification) with real resource-state validation: account publicNetworkAccess=Disabled and the managedNetworks/default isolationMode, with the invoke echo response as the end-to-end proof. * docs(agents): order init before azure.yaml in managed-egress cheatsheet 'azd ai agent init --image' scaffolds azure.yaml/agent.yaml, so it must come before the network: block the reader adds to the generated service. Matches the actual timing and the BYO cheatsheet ordering. * docs(agents): simplify private-networking cheatsheets - Drop the redundant 'azd env set AZD_AGENT_SKIP_ACR true': passing --image to 'azd ai agent init' already derives skipACR() and writes the env var into the environment init creates/selects. Reuse that env (no separate 'azd env new') so init and provision share one environment. - BYO cheatsheet: remove the export-variable indirection; inline placeholders directly into 'azd env set', matching the managed-egress cheatsheet. - Managed-egress cheatsheet: remove the weak 'validate via az show' / env-output block; a successful invoke over the private endpoint is the end-to-end proof. * test(agents): fix jumpbox fallback for DNS-reference deploy In peered fallback mode, populate JB_HOST and wait for SSH before writing /etc/hosts. DNS-reference accounts can also assign different PE IPs per privatelink zone, so pin each account FQDN from the private DNS A record instead of mapping every FQDN to the first PE NIC IP. * test(agents): exclude private-networking e2e harness from PR Remove the ad-hoc live validation harness from the committed diff while keeping it available locally for investigation runs. * test(agents): ignore bicep generator metadata in ARM drift check Compare normalized ARM JSON instead of raw bytes so CI/dev Bicep version metadata does not cause false stale-template failures while still catching semantic template drift. * feat(agents): validate distinct subnet names; drop debug log * feat(agents): refuse Terraform eject when network: is declared The Terraform module has no VNet/private-endpoint/DNS/networkInjections resources, so ejecting it for a network: service would silently drop the config and provision a public account. Fail fast with a clear error instead, preserving the network: secure-by-default contract. Bicep eject remains the supported path for private networking. Also fixes a merge artifact (single-arg ejectInfra call in a test). * docs+test(agents): document Bicep eject customization; verify full network param set - docs: add 'Advanced: eject the Bicep and customize it' section to the private-networking cheatsheet (eject -> manual edit -> provision -> deploy -> invoke), with two worked Bicep edits and a Terraform-unsupported note. - test: assert the complete network parameter set lands in the ejected main.parameters.json for BYO egress, and extend the managed-egress eject test with the full param contract. * docs(agents): merge networking Requirements/Known limitations into one Limitations section * docs(agents): rename networking quick guides to parallel Scenario 1-3 headings * feat: generalize $ref resolver + shared $ref-aware azure.yaml edit helper (#8777) * feat(agents): split Foundry init into per-resource azure.yaml services (#8675) * feat: carry Foundry agent and resource definitions in azure.yaml (#8779) * feat(agents): move Foundry networking to project service (#8809) * feat(agents): move Foundry networking to project service * fix(agents): reject conflicting Foundry network schema * fix(agents): align split Foundry schemas and ACR scan * fix(agents): preserve pre-split Foundry provisioning fallback * docs(agents): split complex Foundry schema example * ci: add cspell words for ai agents extension * ci: exclude gosec G204/G304 for agents test lint * fix: apply go fix and gofmt in agents and skills exts * test: add kind and name to resolveAgentProtocol fixtures * fix: log foundry env fallback and document deploy-context guard * fix: remove foundry agent legacy-config telemetry from azd core * fix: default code-deploy dependency_resolution to remote_build * fix: default rg name and emit AZURE_TENANT_ID in foundry provision * fix: write endpoint on ai-project when reusing existing project * fix: don't declare existing model deployments in azure.yaml * feat: derive azure.yaml project service key from project name * fix: resolve $ref includes when synthesizing foundry infra * fix: harden foundry provisioning provider edge cases * fix: make agent infra eject retryable and reject --image * fix: seed used service names and slices.Sort keys * fix: zip agent override source dir on code deploy * fix: skip deploy upsert for non-key connection auth * feat: keep deprecated agent config shape in schema * fix: debug logs, preserve uses: on optimize apply, acr network isolation * feat: provision model deployments on existing Foundry project * fix(test): update recording tests for inline agent definition The functional recording tests still asserted that agent.yaml exists on disk, but the PR moved agent definitions inline into azure.yaml service entries. Update both Test_AIAgent_Init_NoPrompt_Defer and Test_AIAgent_Init_NoPrompt_WithProject to: - Assert .agentignore exists instead of agent.yaml - Cross-check resolved model name in azure.yaml instead of agent.yaml - Update layout comments to reflect the new structure Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Wei Meng <wemeng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Zhijie Huang <zhihuan@microsoft.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: trangevi <trangevi@microsoft.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
azure.yamlbecomes the single source of truth for a Foundry agent and its companion resources. The agent definition moves off disk into the agent's service entry, and every Foundry resource — the project and its model deployments, connections, toolboxes, skills, and routines — becomes a first-class service with a realazd deploytarget. Existing projects keep working through legacy fallbacks that emit deprecation signals.What changed
azure.yaml. Carried inline on theazure.ai.agentservice entry instead of a separate on-diskagent.yaml.initstops writing that file; every agent command (deploy, run, listen, update, endpoint show) reads from the service entry. Projects on the old on-disk shape still load, with a deprecation warning and a telemetry signal.host: azure.ai.<kind>entries, each owned by its extension.azd deploynow performs a real upsert per resource (previously placeholders);initwrites the entries and wires their provision/deploy order.endpoint:). When a Foundry service setsendpoint:, provisioning is skipped and azd connects to that project instead of creating one.${VAR}from the azd environment at deploy time, while server-side${{...}}placeholders are preserved.azure.yamlJSON schema (stable + alpha) gains per-host validation for all six Foundry hosts; the legacy singlemicrosoft.foundryhost stays accepted so existing projects keep validating.$refresolver, theazure.yamledit helper, and the${VAR}expander move into core (pkg/foundry) so all Foundry extensions share one implementation.Before merge
The
connections,routines, andtoolboxesextensions temporarilyreplacethe azd core dependency with the in-tree checkout to build against the newpkg/foundryhelpers. Remove these directives once the core change lands and bump the published dependency.