Pull request overview

This PR fixes #8923, where azd ai agent init -m <azure.yaml> (the unified Foundry adoption path added in #8885) silently ignored --deploy-mode, --runtime, and --entry-point. After the sample's azure.yaml is adopted, a new applyDeployModeToAdoptedProject hook locates the azure.ai.agent service and applies code- or container-deploy configuration, reusing the same promptDeployMode/promptCodeConfig helpers as the manifest path. Configuration is written back to the service via SetServiceConfigValue.

Changes:

• Add applyDeployModeToAdoptedProject and the applyCodeDeployToService/applyContainerDeployToService/adoptedServiceHasCodeConfig helpers, invoked after scaffolding/provider stamping in runInitFromAzureYaml.
• Resolve deploy mode with explicit-flag precedence, no-op when the sample is already configured, and prompt/auto-select otherwise; write code_configuration/docker/language onto the agent service.
• Add TestAdoptedServiceHasCodeConfig covering nil/empty/struct/null property cases.

The core issue with this PR is a key-casing mismatch: the adopted path reads and writes snake_case (code_configuration, entry_point, dependency_resolution), but the unified azure.yaml inline agent shape and the extension's deploy/read path use camelCase (codeConfiguration, entryPoint, dependencyResolution, per schemas/azure.ai.agent.json and AgentDefinitionInline). Because SetServiceConfigValue writes the path verbatim into azure.yaml, the code configuration this PR writes will not be recognized at deploy time, so --deploy-mode code still has no effect — the bug the PR intends to fix. Detection of already-configured samples and the code→container clear path share the same casing problem, and language/runtime detection runs against . instead of the agent's source subdirectory.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

Two verified issues that affect correctness, plus a robustness concern:

1. Language detection uses project root instead of service directory (HIGH)

\ argetDir := "."\ means \isPythonProject/\isDotnetProject\ scan the project root, but adopted samples declare agent services in subdirectories (e.g., \project: ./agents/assistant). The manifest path uses the downloaded service directory (\init.go:1388). Here, \�gentSvc.GetRelativePath()\ should be used so auto-detection finds the correct files.

2. Non-deterministic map iteration picks an arbitrary service (MEDIUM)

esp.GetProject().GetServices()\ is a map. With multi-agent samples (researcher, writer, triage), the \�reak\ on line 559 applies configuration to whichever service the runtime iterates first. Either apply to all matching services or collect them and let the user choose.

3. Silently discarded \structpb.NewValue\ errors (LOW)

Lines 665 and 697 discard the error from \structpb.NewValue(language)\ with _. While unlikely to fail for string literals, ignoring errors deviates from the extension's error handling conventions.

Note on the existing bot comments about snake_case vs camelCase: those comments cite \internal/project/agent_definition.go\ and \AgentDefinitionInline, neither of which exist in the codebase. The agent_yaml struct uses YAML tag \code_configuration\ and the service target detection (\service_target_agent.go:1122) also reads \code_configuration. The PR's use of snake_case appears internally consistent. I'd recommend verifying which key the deploy path actually reads from the azure.yaml inline properties to confirm end-to-end correctness.

Incremental review of commit 511d165 (--image flag handling in adoption path).

The new �alidateImageFlag + image-override logic is well-structured and the test coverage for validation is solid. Two notes on this new commit:

Prior findings still open:

1. argetDir := "." scans the project root instead of the service subdirectory for language detection (HIGH, line 605). This still causes isPythonProject/isDotnetProject to miss files in samples like ./agents/assistant.
2. Non-deterministic map iteration picks an arbitrary service when multiple �zure.ai.agent services exist (MEDIUM, line 559).

New issue in this commit:

3. imageValue, _ := structpb.NewValue(flags.image) (line 572) discards the error. While �alidateImageFlag already checks the format, structpb.NewValue can still fail for other reasons. This follows the same pattern I flagged in my previous review at line 697.

The --image feature itself looks correct: early validation prevents conflicts with --deploy-mode code, the image property is written before applying container config, and the tests cover the key scenarios. Please address findings 1 and 2 from the prior review before merging.

All three findings from my prior reviews are addressed:

1. Language detection now uses the service's relative path instead of project root.
2. Multi-service case handled correctly by collecting all agent services and iterating the full set.
3. structpb.NewValue errors are no longer silently discarded.

The camelCase key rename (codeConfiguration, entryPoint, dependencyResolution) is consistent with how the deploy path reads these via JSON unmarshal.

@huimiu's observation is correct. I traced the full conversion path:

1. Internal project.ServiceConfig declares Docker DockerProjectOptions as a value type (service_config.go:48), so it's always the zero-value struct when no docker: section exists in azure.yaml.

2. The mapper at mapper_registry.go:165 registers a converter DockerProjectOptions -> *azdext.DockerProjectOptions that unconditionally returns a non-nil pointer (line 193).

3. The ServiceConfig converter at mapper_registry.go:122 calls mapper.Convert(src.Docker, &docker) with that zero-value struct, getting back a non-nil *DockerProjectOptions with all empty fields.

4. Result: svc.GetDocker() != nil is always true after the gRPC round-trip, so the early return on line 612 always fires when flags.deployMode == "".

Fix: mirror the adoptedServiceHasCodeConfig approach by checking additionalProperties for a docker key, or check whether the Docker struct has any non-zero fields (e.g. svc.GetDocker().GetPath() != "" || svc.GetDocker().GetRemoteBuild()). The additionalProperties approach is more consistent with how the deploy path reads these values.

Withdrawing my earlier approval since this means the no-flag adoption path silently skips deploy-mode configuration.

All findings from my prior reviews are addressed in this commit. The adoptedServiceHasDocker function correctly checks additionalProperties instead of svc.GetDocker() (which always returns non-nil due to the gRPC mapper zero-value behavior). The implementation mirrors adoptedServiceHasCodeConfig and the test coverage is solid.

Using UnsetServiceConfig instead of writing null is the correct approach. It properly removes the key rather than leaving an explicit null in the YAML, and the guard conditions avoid unnecessary API calls when the property isn't set.

This applies --deploy-mode / --runtime / --entry-point to the adopted azure.yaml agent service, closing the gap where those flags were silently dropped on the Foundry adoption path. The approach is the right shape: it reuses promptDeployMode / promptCodeConfig, writes codeConfiguration with the same camelCase keys the schema and AgentDefinitionToServiceProperties already use (runtime, entryPoint, dependencyResolution all check out), and the has-code-config / has-docker detection correctly reads additionalProperties rather than trusting the always-non-nil Docker pointer. The added tests cover the detection helpers and image-flag validation well.

One thing worth resolving before merge: applyContainerDeployToService hardcodes remoteBuild: true, while the code-based init path turns it off for VNET network-injected Foundry projects, so adopting a container sample against such a project will fail the first deploy and require a manual edit. The map-iteration ordering is a minor nondeterminism nit for the multi-agent case. Nothing else blocks; the key handling and the respect-existing-sample logic are correct as written.