Hook up Azure Deployer to BicepProvisioner #10845

captainsafia · 2025-08-06T00:33:33Z

Contributes towards #10448.

The next step here is to revise the APIs for IBicepProvisioner so that it is possible to query the ARM deployment to get the status on each subresource that is deployed from main.bicep. The current BicepProvisioner implementation assumes that only one resource is deployed and that status is set through the ResourceNotificationService.

Copilot

Pull Request Overview

This PR connects the Azure Deployer to the BicepProvisioner, enabling deployment-time provisioning of Azure resources. The changes focus on extending the existing provisioning infrastructure to handle both run-time and deploy-time scenarios.

Key changes:

Enhanced ProvisioningContext to include execution context and output path information
Modified BicepProvisioner to handle both subscription-scoped and resource group-scoped deployments
Connected AzureEnvironmentResource to use BicepProvisioner during deployment phase

Reviewed Changes

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

Show a summary per file

File	Description
src/Aspire.Hosting.Azure/Provisioning/ProvisioningContext.cs	Added execution context and output path to provisioning context
src/Aspire.Hosting.Azure/Provisioning/Provisioners/IBicepProvisioner.cs	New interface for Bicep provisioning operations
src/Aspire.Hosting.Azure/Provisioning/Provisioners/BicepProvisioner.cs	Enhanced to support both run-time and deploy-time provisioning modes
src/Aspire.Hosting.Azure/AzureEnvironmentResource.cs	Changed inheritance to AzureBicepResource and integrated deployment logic
src/Aspire.Hosting.Azure/AzureDeployingContext.cs	Added comprehensive deployment orchestration with parameter mapping
src/Aspire.Hosting.Azure/AzureBicepResource.cs	Fixed template file path handling for custom output directories
tests/Aspire.Hosting.Azure.Tests/*	Updated test infrastructure to support new interfaces and parameters
playground/deployers/Deployers.AppHost/*	New playground project demonstrating Azure deployment capabilities

Comments suppressed due to low confidence (1)

tests/Aspire.Hosting.Azure.Tests/ProvisioningTestHelpers.cs:187

The TestArmDeploymentCollection implementation is referenced but not defined in this file. This could cause test failures if the implementation is missing or incomplete.

    public IArmDeploymentCollection GetArmDeployments()

Copilot · 2025-08-06T00:34:07Z

src/Aspire.Hosting.Azure/Provisioning/Provisioners/BicepProvisioner.cs

+            if (context.ExecutionContext.IsRunMode)
+            {
+                template.Dispose();
+            }


The disposal of the template should happen regardless of execution mode. Moving the template.Dispose() call outside the if block would ensure proper resource cleanup in all scenarios.

Suggested change

if (context.ExecutionContext.IsRunMode)

{

template.Dispose();

}

template.Dispose();

Copilot · 2025-08-06T00:34:08Z

src/Aspire.Hosting.Azure/AzureDeployingContext.cs

+                    // TODO: Prompt here.
+                    await deployingStep.FailAsync("Deployment contains unresolvable parameters.", cancellationToken).ConfigureAwait(false);


The TODO comment indicates incomplete functionality for handling unresolvable parameters. This could leave the deployment in an inconsistent state without proper parameter resolution.

Suggested change

// TODO: Prompt here.

await deployingStep.FailAsync("Deployment contains unresolvable parameters.", cancellationToken).ConfigureAwait(false);

throw new InvalidOperationException(

$"Deployment contains unresolvable parameter: '{provisioningParameter.BicepIdentifier}'. " +

"Please ensure all required parameters are provided or handled before deployment.");

captainsafia · 2025-08-06T00:34:54Z

src/Aspire.Hosting.Azure/Provisioning/Internal/DefaultProvisioningContextProvider.cs

        if (string.IsNullOrEmpty(_options.ResourceGroup))
        {
            // Generate an resource group name since none was provided
            // Create a unique resource group name and save it in user secrets


We never create a resource group via the ProvisioningContextProvider when in publish mode and always rely on it to be provisoned via the declaration in main.bicep.

captainsafia · 2025-08-06T00:36:07Z

src/Aspire.Hosting.Azure/Provisioning/Internal/DefaultProvisioningContextProvider.cs

        }

        var principal = await userPrincipalProvider.GetUserPrincipalAsync(cancellationToken).ConfigureAwait(false);
+        var outputPath = _publishingOptions.OutputPath is { } outputPathValue ? Path.GetFullPath(outputPathValue) : null;


We past the output path to the ProvisioningContext during deployment so that we can reuse the bicep templates that were generated by the publish step during deployment.

captainsafia · 2025-08-06T00:37:15Z

src/Aspire.Hosting.Azure/Provisioning/Provisioners/BicepProvisioner.cs

-        }),
-        cancellationToken).ConfigureAwait(false);
+        })
+        { Location = context.Location },


ARM requires a location when doing a subscription-scoped deployment so we pass it to ArmDeploymentContent here. There's no consequence to setting the location for RG-based deployments so setting this up conditionally.

captainsafia · 2025-08-06T00:38:21Z

src/Aspire.Hosting.Azure/Provisioning/Provisioners/BicepProvisioner.cs

-        var deployments = resourceGroup.GetArmDeployments();
+        // Deploy-time provisioning should target the subscription scope while run-time
+        // provisioning should target the resource group scope.
+        var deployments = context.ExecutionContext.IsPublishMode


This is one of the places where we need to differentiate between run-mode and publish-mode in the provisioner. Deployments during publish-mode are subscription scoped and need to be resolved differently.

This shouldn't be based on the mode. This should be part of the Scope property on the AzureBicepResource. We'll need to do this #7514 and I suspect it'll look similar to this.

captainsafia · 2025-08-06T00:39:39Z

src/Aspire.Hosting.Azure/Provisioning/Provisioners/BicepProvisioner.cs

        if (deployment.Data.Properties.ProvisioningState == ResourcesProvisioningState.Succeeded)
        {
-            template.Dispose();
+            if (context.ExecutionContext.IsRunMode)


We want to keep the template files used to do the deployment around during deploy mode (for now: see #10642).

captainsafia · 2025-08-06T00:40:32Z

src/Aspire.Hosting.Azure/Provisioning/Provisioners/IBicepProvisioner.cs

+/// <summary>
+/// Provides functionality for provisioning Azure Bicep resources.
+/// </summary>
+internal interface IBicepProvisioner


This interface exists to support testability. We need an IBicepProvisioner implementation that no-ops in tests.

captainsafia · 2025-08-06T00:41:23Z

src/Aspire.Hosting.Azure/Provisioning/Provisioners/IBicepProvisioner.cs

+    /// <param name="context">The provisioning context containing Azure subscription, resource group, and other deployment details.</param>
+    /// <param name="cancellationToken">A cancellation token to cancel the operation.</param>
+    /// <returns>A task that represents the asynchronous operation.</returns>
+    Task GetOrCreateResourceAsync(AzureBicepResource resource, ProvisioningContext context, CancellationToken cancellationToken);


This method currently returns no value but I can see it evolving to return a type that we can use to poll the underlying ArmOperation for their state so we can get granular state updates on each resource deployed from main.bicep in the future.

captainsafia · 2025-08-06T00:45:02Z

src/Aspire.Hosting.Azure/AzureEnvironmentResource.cs

 /// </summary>
 [Experimental("ASPIREAZURE001", UrlFormat = "https://aka.ms/dotnet/aspire/diagnostics#{0}")]
-public sealed class AzureEnvironmentResource : Resource
+public sealed class AzureEnvironmentResource : AzureBicepResource


AzureEnvironmentResource needs to implement AzureBicepResource so we can set parameters and store outputs from the ARM deployment, like the ACR instance associated with a container apps environment for future image pushes.

So this represents main.bicep now? Should this be an AzureProvisoningResource instead?

So this represents main.bicep now?

Yep.

Should this be an AzureProvisoningResource instead?

AzureProvisioningResource encodes some concepts that I don't think make sense for main.bicep (role assignments, existing resources). Also, main.bicep isn't a provisionable resource itself but more so a set of provisioned resources so I feel like it makes more sense to just model it as a Bicep resource.

Why not make it one? The underlying logic in AzureProvisioningContext creates an infrastructure object. I don’t think it need to be in this PR

Why it make it one?

We need to be able to set outputs from the deployment onto the AzureEnvironmentResource so that we can propogate them to future steps (e.g. resolving the registry info for the ACR instance that we automatically provision) and we need a shape that matches the API of the AzureBicepProvisioner.

If AzureEnvironmentResource doesn't implement AzureBicepResource, how do you initiate the provisioning of main.bicep without modifying BicepProvisioner?

playground/deployers/Deployers.AppHost/AppHost.cs

mitchdenny · 2025-08-06T01:28:51Z

Do I need to pre-create the resource group at the moment?

mitchdenny · 2025-08-06T01:30:46Z

So I jumped straight into doing aspire deploy ... I didn't run it first - so the parameters were not set.

captainsafia · 2025-08-06T01:38:05Z

Do I need to pre-create the resource group at the moment?

Uh-oh! I think this is something I need to fix. I realize I didn't validate the "create resource group from main bicep" flow since I was using an existing resource group.

mitchdenny · 2025-08-06T01:38:40Z

Failing to provision in the dashboard also:

mitchdenny · 2025-08-06T01:42:40Z

So it looked to me like it was building the storage roles and storage templates simultaneously in the dashboard. That is probably OK - but I'm wondering if it tries to start deploying them simultaneously as well which would be an issue.

src/Aspire.Hosting.Azure/AzureBicepResource.cs

davidfowl · 2025-08-06T02:23:13Z

src/Aspire.Hosting.Azure/AzureDeployingContext.cs

-        await provisioningContextProvider.CreateProvisioningContextAsync(userSecrets, cancellationToken).ConfigureAwait(false);
+        var provisioningContext = await provisioningContextProvider.CreateProvisioningContextAsync(userSecrets, cancellationToken).ConfigureAwait(false);
+
+        if (resource.PublishingContext is null)


How does this happen?

Currently -- never. I left this as an explicit check for when we do #10620.

captainsafia · 2025-08-06T22:33:46Z

@mitchdenny b8beec3 includes fixes for the two issues you ran into.

The exception you got during aspire deploy about resource groups was due to the fact that I was skipping automatic resource group creation via the ProvisioniningContextProvider during publish so that we can rely on the provisioning that happens in main.bicep.

Adding some more conditional logic based on modes to the context provider was annoying but I realized that resource group creation is idempotent since we use ArmDeploymentMode.Incremental so we can always create the resource group via the SDK on the apphost side and not need to change the bicep.

The other issue was due to the fact that setting the Location on the ARM demployment is only supported on subscription-scoped deployments, which we only do during aspire deploy.

mitchdenny · 2025-08-12T01:35:19Z

@captainsafia

So I tried to deployt he CosmosEndToEnd using this - initially to Australia Southeast. I got an error, I think it was a capacity issue, so I'm attempting to deploy to West US3 now, but now I'm getting the following error:

I'm guessing the deployment name is deterministic? We might need the location for the deployment to be made part of the hash being used to determine the deployment name.

mitchdenny · 2025-08-12T01:36:51Z

(it was a quota issue BTW)

mitchdenny · 2025-08-12T01:54:16Z

So once I cleared out the old deployment the deployment completed successfully, but the container app wasn't deployed (the environment was though). Just not there yet?

mitchdenny · 2025-08-12T01:55:09Z

.. container images didn't get pushed either.

mitchdenny

overall I think this looks like a good incremental step. What are the issues with merging this now in terms of shipping 9.5?

davidfowl · 2025-08-12T02:02:03Z

Biggest problem is have (and it's small) is this

mitchdenny · 2025-08-12T02:15:32Z

Because of the scope of this change we want to get this in earlier than later so we can flush out any issues.

captainsafia · 2025-08-12T16:36:59Z

I'm guessing the deployment name is deterministic? We might need the location for the deployment to be made part of the hash being used to determine the deployment name.

Yep, it's just based on the Azure environment resource name which is in turn based on the AppHost hash. I'll push a change here to make it more unique to the deployment.

So once I cleared out the old deployment the deployment completed successfully, but the container app wasn't deployed (the environment was though). Just not there yet?

Yep, this change only deploys the "main.bicep" to the target environment. It doesn't handle pushing container images or deploying the container app instances themselves. The prototype branch shows what the north star looks like here although I dunno if the "push image to registry" action will end up being inlined.

Because of the scope of this change we want to get this in earlier than later so we can flush out any issues.

Yeah, #10448 tracks the overall flow here and followup issues.

Biggest problem is have (and it's small) is #10845 (comment)

Ah, I missed this comment earlier. I'll have to wrap my head around what the API shape for this would look like but I do agree that there is probably some relationship between existing resources in another subscription and this change. I think this is where we probably need to start modeling SubscriptionResource and ResourceGroupResource more clearly in the app model.

mitchdenny · 2025-08-13T06:19:01Z

Yep, it's just based on the Azure environment resource name which is in turn based on the AppHost hash. I'll push a change here to make it more unique to the deployment.

Check in with what AZD does here. There is a balance to be had. We don't want deployments of the same apphost to two different RGs to conflict with their generated deployment ID, but there is a limit to the number of deployments within a subscription and then yuo have to go an purge old deployments - so you don't necessarily want to recreate it each time. It might make sense to replicate what AZD does here.

captainsafia · 2025-08-13T19:42:47Z

Yep, it's just based on the Azure environment resource name which is in turn based on the AppHost hash. I'll push a change here to make it more unique to the deployment.

Check in with what AZD does here. There is a balance to be had. We don't want deployments of the same apphost to two different RGs to conflict with their generated deployment ID, but there is a limit to the number of deployments within a subscription and then yuo have to go an purge old deployments - so you don't necessarily want to recreate it each time. It might make sense to replicate what AZD does here.

Yep, c2b96cd uses Unix timestamp to differentiate the same way azd does.

azd uses the environment name (aka resource group name) as the prefix whereas we're currently using the resource name (which is hashed with the AppHost SHA). The timestamp suffix feels like a good enough differentiator for now although we might end up incoroporating the environment name into the deployment name too.

mitchdenny · 2025-08-15T00:26:40Z

@captainsafia ship it!

Copilot AI review requested due to automatic review settings August 6, 2025 00:33

github-actions bot added the area-app-model Issues pertaining to the APIs in Aspire.Hosting, e.g. DistributedApplication label Aug 6, 2025

Copilot AI reviewed Aug 6, 2025

View reviewed changes

captainsafia commented Aug 6, 2025

View reviewed changes

captainsafia added area-deployment azure Issues associated specifically with scenarios tied to using Azure and removed area-app-model Issues pertaining to the APIs in Aspire.Hosting, e.g. DistributedApplication labels Aug 6, 2025

captainsafia requested review from mitchdenny and sebastienros August 6, 2025 00:48

captainsafia mentioned this pull request Aug 6, 2025

Expose strongly-typed deployment response from BicepProvisioner #10846

Closed

mitchdenny reviewed Aug 6, 2025

View reviewed changes

playground/deployers/Deployers.AppHost/AppHost.cs Show resolved Hide resolved

davidfowl reviewed Aug 6, 2025

View reviewed changes

src/Aspire.Hosting.Azure/AzureBicepResource.cs Show resolved Hide resolved

davidfowl reviewed Aug 6, 2025

View reviewed changes

captainsafia added 2 commits August 11, 2025 17:38

Hook up Azure Deployer to BicepProvisioner

a1d7097

Fix up greenfield and run-mode provisioning

9738c8e

captainsafia force-pushed the safia/bicep-provisioner-deploy branch from b8beec3 to 9738c8e Compare August 12, 2025 00:38

mitchdenny reviewed Aug 12, 2025

View reviewed changes

Disambiguate deployment names and fix principal ID

c2b96cd

Update snapshot to include principalId

e860eb8

mitchdenny approved these changes Aug 15, 2025

View reviewed changes

captainsafia merged commit 1d7256f into main Aug 15, 2025
292 checks passed

captainsafia deleted the safia/bicep-provisioner-deploy branch August 15, 2025 00:44

dotnet-policy-service bot added this to the 9.5 milestone Aug 15, 2025

github-actions bot locked and limited conversation to collaborators Sep 14, 2025

		// TODO: Prompt here.
		await deployingStep.FailAsync("Deployment contains unresolvable parameters.", cancellationToken).ConfigureAwait(false);

-                    // TODO: Prompt here.
-                    await deployingStep.FailAsync("Deployment contains unresolvable parameters.", cancellationToken).ConfigureAwait(false);
+                    throw new InvalidOperationException(
+                        $"Deployment contains unresolvable parameter: '{provisioningParameter.BicepIdentifier}'. " +
+                        "Please ensure all required parameters are provided or handled before deployment.");

Hook up Azure Deployer to BicepProvisioner #10845

Hook up Azure Deployer to BicepProvisioner #10845

Uh oh!

Conversation

captainsafia commented Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davidfowl Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mitchdenny commented Aug 6, 2025

Uh oh!

mitchdenny commented Aug 6, 2025

Uh oh!

captainsafia commented Aug 6, 2025

Uh oh!

mitchdenny commented Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mitchdenny commented Aug 6, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

captainsafia commented Aug 6, 2025

Uh oh!

mitchdenny commented Aug 12, 2025

Uh oh!

mitchdenny commented Aug 12, 2025

Uh oh!

mitchdenny commented Aug 12, 2025

Uh oh!

mitchdenny commented Aug 12, 2025

Uh oh!

mitchdenny left a comment

Choose a reason for hiding this comment

Uh oh!

davidfowl commented Aug 12, 2025

Uh oh!

mitchdenny commented Aug 12, 2025

Uh oh!

captainsafia commented Aug 6, 2025 •

edited

Loading

davidfowl Aug 12, 2025 •

edited

Loading

mitchdenny commented Aug 6, 2025 •

edited

Loading