fix: set brownfield Foundry projectName without ACR#8917
Open
huimiu wants to merge 3 commits into
Open
Conversation
huimiu
requested review from
JeffreyCA,
RickWinter,
glharper,
hemarina,
hund030,
tg-msft,
therealjohn,
trangevi,
trrwilson and
vhvb1989
as code owners
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes an InvalidTemplate ARM error in the azure.ai.agents extension when deploying a brownfield (endpoint:) Foundry project that declares model deployments but does not create an ACR. Previously, the projectName ARM parameter was only set inside the createACR branch of brownfieldParams, so the no-ACR path left it empty. Because brownfield.arm.json unconditionally references the existing Microsoft.CognitiveServices/accounts/projects resource with name <accountName>/<projectName>, an empty projectName produced a single-segment name and failed ARM validation. The fix moves projectName out of the conditional so it is always set, while ACR-only params remain gated on createACR.
Changes:
- Always set the
projectNameparam inbrownfieldParams, independent ofcreateACR. - Update
TestBrownfieldParamsto setbrownfieldEndpointand assertprojectNameis present in the no-ACR case. - Add a CHANGELOG entry documenting the fix.
Reviewed changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| cli/azd/extensions/azure.ai.agents/internal/project/foundry_provisioning_provider.go | Moves projectName param out of the createACR branch so it is always set; adds explanatory comment. |
| cli/azd/extensions/azure.ai.agents/internal/project/foundry_provisioning_provider_brownfield_acr_test.go | Updates the no-ACR subtest to set brownfieldEndpoint and assert projectName resolves correctly. |
| cli/azd/extensions/azure.ai.agents/CHANGELOG.md | Adds a Bugs Fixed entry for the brownfield projectName fix. |
| .impeccable/hook.cache.json | Stray local tooling cache artifact unrelated to the fix; should be removed and gitignored. |
The core fix is minimal, correct, and reuses the existing brownfieldProjectName() resolver already used on the ACR path, so it introduces no regression. The only concern is the unrelated .impeccable/hook.cache.json cache file that appears to have been committed accidentally.
Files not reviewed (1)
- .impeccable/hook.cache.json: Generated file
huimiu
changed the title
huimiu
force-pushed
the
hui/fix-foundry-project-name
branch
2 times, most recently
from
66fbd54 to
362c097
Compare
huimiu
changed the title
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
approved these changes
Jul 1, 2026
jongio
left a comment
jongio
left a comment
Member
There was a problem hiding this comment.
Clean, well-scoped fix. The root cause (projectName only set inside the createACR branch while the ARM template unconditionally references the accounts/projects resource) is correctly identified and addressed.
The fix moves projectName into the unconditional params block, which is the right layer. The test now covers the no-ACR case with a real endpoint and asserts the two-segment name resolves. No regressions expected since brownfieldProjectName() was already exercised on the ACR path.
📋 Prioritization NoteThanks for the contribution! The linked issue isn't in the current milestone yet. |
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.
Fixes #8920
TL;DR
Running
azd provision/azd deployon an existing Foundry project that adds model deployments without creating a container registry failed with an ARMInvalidTemplateerror. The requiredprojectNamevalue was only passed to the template when a registry was also being created. This PR always passes it.Who hits this
Any brownfield Foundry project service (
host: azure.ai.projectwith anendpoint:) that:deployments:, andcodeConfiguration) — so no container registry (ACR) is created.Symptom
The resource name is missing its second segment: it should be
<account>/<project>but came out as just<account>/.Root cause
brownfield.arm.jsonalways references the existing project resource, whose ARM name isformat('{0}/{1}', accountName, projectName). ButbrownfieldParamsonly set theprojectNameparameter inside theif createACRbranch. With no ACR,projectNamefell back to the template default'', producing the invalid single-segment name<accountName>/.Fix
Move
projectNameout of thecreateACRbranch so it is always set (resolved from the project endpoint). ACR-only params (includeAcr,acrName,tags,location) stay gated oncreateACR.How to verify
azd provision --previewon such a project runs an ARM what-if through the same code path (and creates nothing):InvalidTemplateerror above.<account>/<project>resource.Tests
TestBrownfieldParamsnow assertsprojectNameis present in the no-ACR case.Related
A separate azure.yaml serialization issue for code-less hosts (invalid
project: ""/language: "") surfaced during this work and is tracked in #8919.