feat: add Foundry project add workflow - #9559
Conversation
|
Azure Pipelines: Successfully started running 1 pipeline(s). 20 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
📋 Prioritization NoteThanks for the contribution! The linked issue isn't in the current milestone yet. |
|
Azure Pipelines: Successfully started running 1 pipeline(s). 20 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
There was a problem hiding this comment.
Pull request overview
Adds Foundry project ownership and authoring to azure.ai.projects.
Changes:
- Adds project initialization, adoption, and infrastructure ejection.
- Adds managed model deployment authoring.
- Adds delegated contracts, reconciliation, environment updates, and tests.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
internal/exterrors/errors.go |
Adds compatibility errors. |
internal/cmd/root.go |
Registers new commands. |
internal/cmd/project_service_reconciler.go |
Reconciles project services. |
internal/cmd/project_ownership_test.go |
Adds ownership-flow tests. |
internal/cmd/project_init.go |
Implements project initialization and ejection. |
internal/cmd/project_environment.go |
Manages project environment state. |
internal/cmd/project_deployment.go |
Selects and reconciles deployments. |
internal/cmd/project_deployment_add.go |
Implements deployment addition. |
internal/cmd/delegated_contract.go |
Defines delegated request contracts. |
go.mod |
Promotes RPC types to a direct dependency. |
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Travis Angevine (trangevi)
left a comment
There was a problem hiding this comment.
I'm concerned about adding new commands before we have closure on the new proposed end to end path which John has been working on. Let's sync on that before moving forward with the new commands here
azure.ai.agents PR buildNote This is an unsigned development build. Install it only if you trust this PR. Install the extension: azd ext install "https://azuresdkartifacts.z5.web.core.windows.net/azd/extensions/pr/9559/azure-ai-agents.zip"
|
azure.ai.projects PR buildNote This is an unsigned development build. Install it only if you trust this PR. Install the extension: azd ext install "https://azuresdkartifacts.z5.web.core.windows.net/azd/extensions/pr/9559/azure-ai-projects.zip"
|
Closes #9564
Why this is needed
azure.ai.projectsalready ownshost: azure.ai.project, but adding a managed model deployment still required a separate project initialization step. That extra step blocks Foundry extensions from using resource-specificaddcommands, and azd core does not have an incremental add experience yet.What this PR does
azd ai project addauthors a new Foundry project service, adopts an existing project by ARM resource ID, or configures an endpoint-only existing project.azd ai project initstays public with the same flags, validation, and mutation path so current users and Agents callers keep working.azd ai project deployment addcreates the minimum azd workspace state and a missingazure.ai.projectservice before it writes a managed model deployment. Direct commands and delegated requests share that behavior. Workspace bootstrap still uses the existing empty-template flow.azd init --minimalis unchanged.Delegated requests still accept
azure.ai.agents/init. Project identity, Azure context, legacy project services, and project ID/location checks stay in place where resource reconciliation needs them. Updates stay idempotent and leave unrelated service fields alone. If a later deployment step fails, the authored project service is kept so the command can be retried.Bicep and Terraform ejection still cover root and layered projects, including existing-project ownership checks and rollback on failed updates. Docs and tests cover command parity, self-initialization, and setup failures that must not write deployment configuration.
Why this approach
This is an extension-owned bridge until azd core has its own incremental add experience. Both public commands use one in-process authoring action. Deployment add calls that action directly with intermediate output disabled, instead of launching another Projects command. Validation, mutation, rollback, and output stay in one place, and the logic stays reusable if the extension later forwards to a core
azd addcommand.A Foundry project is valid without a model deployment, so a project service created before a later model-selection or deployment-reconciliation failure stays in the workspace.
This work covers the Projects side only. It does not add an Agents
addcommand or accept delegated sources other thanazure.ai.agents/init.project set,show, andunsetstill only manage runtime context and do not authorazure.yaml. These commands update local project and environment configuration; Azure resources are created or updated later byazd provisionorazd up. Design #9441 still usesproject initas the primary spelling and should be updated.Related to #9085. Based on the ownership design in #9441.
Validation
Projects extension tests and build pass.
go fix,golangci-lint, and the Go spelling check pass. Fake-host tests cover direct and delegated deployment add when the project service is missing, and project setup failure before deployment mutation.