[azure.ai.agents] Support reusing an existing ACR during greenfield Foundry provisioning
- Dominant language
- Go
- Stars
- 569
- Forks
- 364
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 136
Description
## Scenario
I am provisioning a new Microsoft Foundry project with a hosted agent that builds its container image from source.
My organization already has an Azure Container Registry prepared for this workload. The registry may be centrally managed or created in advance to satisfy organizational requirements such as naming, networking, access control, or resource ownership.
I would like to provide the existing registry to azd and have the greenfield Foundry provisioning flow use it for the hosted agent build and publish workflow.
The registry information may already be available in the azd environment, for example:
- `AZURE_CONTAINER_REGISTRY_RESOURCE_ID`
- `AZURE_CONTAINER_REGISTRY_ENDPOINT`
## Current behavior
For a greenfield project using `infra.provider: microsoft.foundry`, a hosted agent without `image` or `codeConfiguration` is treated as a source-build agent and azd provisions a new ACR.
The provisioning decision does not currently consider an existing ACR supplied through the azd environment. As a result, azd may create a second registry even when the user has already prepared one.
The generated provisioning outputs can then replace the existing registry endpoint and resource ID in the azd environment with values for the newly created registry.
Adding an `image` value to the service can suppress automatic ACR creation, but that describes a prebuilt-image scenario rather than the intended source-build workflow.
## Desired scenario
For a greenfield hosted-agent source-build workflow, users should be able to tell azd to use an existing ACR instead of creating another one.
The new Foundry project should be connected to the provided registry, and subsequent package and publish operations should continue using that registry.
This would support organizations that manage shared or pre-provisioned registries while preserving the normal azd source-build experience.
## Related context
- #8861 and #8880 ensured that hosted source-build agents always have an ACR available.
- #9078 covers discovering or configuring an ACR when using an existing Foundry project.
- #9224 and #9225 validate ACR connections discovered from an existing project.
This request is specifically about reusing an existing ACR while provisioning a new Foundry project.
Contributor guide
Research direction
Start at the greenfield `microsoft.foundry` provisioning flow for hosted-agent source builds and trace how it decides whether to create an ACR. Check how `AZURE_CONTAINER_REGISTRY_RESOURCE_ID` and `AZURE_CONTAINER_REGISTRY_ENDPOINT` are consumed and how provisioning outputs are written back. Done means a supplied registry is reused for the new Foundry project and later package and publish operations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, go
- Domain
- cli, cloud
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100