Azure / Azure/azure-dev

[azure.ai.agents] Support reusing an existing ACR during greenfield Foundry provisioning

Open
#10,022 0 comments 0 reactions 0 assignees View on GitHub
area/provisioning enhancement ext-agents ext-projects
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.