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

@@ -217,14 +220,14 @@ public async Task<ProvisioningContext> CreateProvisioningContextAsync(JsonObject
            // 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

@@ -259,6 +262,7 @@ public async Task<ProvisioningContext> CreateProvisioningContextAsync(JsonObject
        }

        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

@@ -198,48 +205,54 @@ await notificationService.PublishUpdateAsync(resource, state =>

        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

@@ -17,7 +19,7 @@ namespace Aspire.Hosting.Azure;
 /// Emits a <c>main.bicep</c> that aggregates all provisionable resources.
 /// </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?

mitchdenny · 2025-08-06T01:21:26Z

playground/deployers/Deployers.AppHost/AppHost.cs

@@ -0,0 +1,22 @@
+var builder = DistributedApplication.CreateBuilder(args);
+
+builder.AddAzureContainerAppEnvironment("env");


Its kind of strange that we add AddAzureContainerAppEnvironment(...) when we aren't using anything other than Azure resources. I realize this is probably just the case for this playground but I wonder if we will see cases of people using apphosts to deploy things without any compute (containers/projects) because the resources they deploy have some built-in compute functionality that they are leveraging.

In which case - does that API name make sense?

I could see a world where you only only use Aspire deploy to deploy Azure resources and not any actual compute resources. For example, I saw a scenario recently on a static front-end deployed on an Azure Storage instance with Azure Front Door for routing.

We've set up the APIs for AddAcaEnv such that you don't really "discover" you need them until you try to publish or deploy a project with compute resources (or role assignments).

We've really overloaded the term "environment" in our APIs and I'm not sure how we dig ourselves out of it. Although it won't really be exposed in public API to the user until the add compute.

Today we need a compute environment or we'll generate invalid bicep. If you provision an azure resource that depends on managed identity (which we do by default) but don't provide a compute environment, we'll generate invalid bicep (with a missing user assigned managed identity).

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.

Hook up Azure Deployer to BicepProvisioner

a9219c9

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

Open

mitchdenny reviewed Aug 6, 2025

View reviewed changes

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

Fix up greenfield and run-mode provisioning

b8beec3

		// 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.");

		@@ -217,14 +220,14 @@ public async Task<ProvisioningContext> CreateProvisioningContextAsync(JsonObject
		// Create a unique resource group name and save it in user secrets

		@@ -0,0 +1,22 @@
		var builder = DistributedApplication.CreateBuilder(args);

		builder.AddAzureContainerAppEnvironment("env");

Hook up Azure Deployer to BicepProvisioner #10845

Are you sure you want to change the base?

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

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!

Uh oh!

captainsafia commented Aug 6, 2025 •

edited

Loading

mitchdenny commented Aug 6, 2025 •

edited

Loading