aspire do-deploy-<x>: Doesn't resolve all dependencies

[mip1983]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I'm using the 'aspire do' command in my Azure DevOps pipeline to be able to deploy individual projects in my app. However I've hit a couple of scenarios so far where I've got to deploy a specific project or function app and it's not come up due to dependency issues.

So for example, I have an api project with a dependency on CosmosDb which is configured 'WithAccessKeyAuthentication' and pointed at a key vault. When I run 'aspire do deploy-my-api', it fails because it can't find the connection string secret in said key vault (as it's not been provisioned yet) nor does it at that point have it's managed identity assigned permissions on that key vault yet.

So ahead of 'aspire do deploy-my-api', I need to do 'do provision-my-api-identity' and 'do provision-my-api-roles-secrets' to get this to work.

It's a similar story with my azure function apps. They are configured 'WithHostStorage' pointed at a particular storage account, and roles assigned on that 'WithRoleAssignments'. However if I 'aspire do deploy-my-function-app', I need to provision the identity and roles ahead of that manually or it puts the function app out unable to function/talk to host storage.

Expected Behavior

Doing 'aspire do-deploy-' should recognize key dependencies and role assignments and provision those.

Steps To Reproduce

Take a starter aspire template and create an initial deployment for it in azure with 'aspire deploy'.

add a function app on a timer trigger and azure blob storage.

Assign that storage account to the function app.

.WithHostStorage("storage")
.WithRoleAssignments("storage",
    StorageBuiltInRole.StorageBlobDataOwner,
    StorageBuiltInRole.StorageAccountContributor,
    StorageBuiltInRole.StorageTableDataContributor)

Now try 'aspire do deploy-my-functionapp', you'll see it fail to run and complain about permissions on storage.

Exceptions (if any)

No response

.NET Version info

.NET SDK:
Version: 10.0.102
Commit: 4452502459
Workload version: 10.0.102
MSBuild version: 18.0.7+445250245

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26200
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\10.0.102\

.NET workloads installed:
[android]
Installation Source: SDK 10.0.100, VS 18.2.11415.280, VS 18.3.11426.168
Manifest Version: 36.1.12/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.android\36.1.12\WorkloadManifest.json
Install Type: Msi

[ios]
Installation Source: SDK 10.0.100, VS 18.2.11415.280, VS 18.3.11426.168
Manifest Version: 26.2.10191/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.ios\26.2.10191\WorkloadManifest.json
Install Type: Msi

[maccatalyst]
Installation Source: SDK 10.0.100, VS 18.2.11415.280, VS 18.3.11426.168
Manifest Version: 26.2.10191/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.maccatalyst\26.2.10191\WorkloadManifest.json
Install Type: Msi

[maui-windows]
Installation Source: SDK 10.0.100, VS 18.2.11415.280, VS 18.3.11426.168
Manifest Version: 10.0.1/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.maui\10.0.1\WorkloadManifest.json
Install Type: Msi

[wasm-tools]
Installation Source: SDK 10.0.100, VS 18.2.11415.280, VS 18.3.11426.168
Manifest Version: 10.0.102/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.current\10.0.102\WorkloadManifest.json
Install Type: Msi

[wasm-tools-net9]
Installation Source: SDK 10.0.100, VS 18.3.11426.168
Manifest Version: 10.0.102/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.net9\10.0.102\WorkloadManifest.json
Install Type: Msi

Configured to use workload sets when installing new manifests.

Host:
Version: 10.0.2
Architecture: x64
Commit: 4452502459

.NET SDKs installed:
9.0.310 [C:\Program Files\dotnet\sdk]
10.0.101 [C:\Program Files\dotnet\sdk]
10.0.102 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Anything else?

No response

[davidfowl]

Use aspire do diagnostics and look at the dependency graph (or feed to it an agent), usually there's a higher level step that you can invoke.

[mip1983]

Use aspire do diagnostics and look at the dependency graph (or feed to it an agent), usually there's a higher level step that you can invoke.

I've had a bit more of a closer look with do diagnostics (discovered I can do 'aspire do diagnostics | clip' and paste into a text file, as windows terminal likes to jump/scroll to the bottom at random for some reason).

I saw 'Step: provision-azure-bicep-resources', and thought ah, maybe this is the equivalent of running 'azd provision' like I did previously, i.e. giving me all the azure resources/roles/permissions etc without deploying the container apps. But sadly no, this seems to deploy everything, so not sure it's functionally much different a step to just running aspire deploy.

Maybe it would be useful if this tool did produce an aggregation step that was functionally equivalent to 'azd provision', i.e. everything around the container apps but not the apps/functions themselves? In the mean time, I can't really see an alternative for deploying an individual container other than manually figuring out what provisioning steps I need to run ahead of it for roles.

Edit:

Here's a sample from my aspire do-diagnostics output:

10:20:14 (diagnostics) i If targeting 'deploy-capture-api':
10:20:14 (diagnostics) i   Direct dependencies: print-capture-api-summary
10:20:14 (diagnostics) i   Total steps: 18
10:20:14 (diagnostics) i   Execution order:
10:20:14 (diagnostics) i     [0] process-parameters
10:20:14 (diagnostics) i     [1] build-prereq | deploy-prereq (parallel)
10:20:14 (diagnostics) i     [2] build-capture-api | validate-azure-login (parallel)
10:20:14 (diagnostics) i     [3] create-provisioning-context
10:20:14 (diagnostics) i     [4] provision-cae-ecodriver-acr | provision-capture-api-identity | provision-capture-api-insights | provision-secrets | 
provision-storage (parallel)
10:20:14 (diagnostics) i     [5] login-to-acr-cae-ecodriver-acr | provision-cae-ecodriver (parallel)
10:20:14 (diagnostics) i     [6] push-prereq
10:20:14 (diagnostics) i     [7] push-capture-api
10:20:14 (diagnostics) i     [8] provision-capture-api-containerapp
10:20:14 (diagnostics) i     [9] print-capture-api-summary
10:20:14 (diagnostics) i     [10] deploy-capture-api

You can see step 4, it does call the provisioning on the dependencies, but maybe the default behavior should include the roles?

e.g.

4] provision-cae-ecodriver-acr | provision-capture-api-identity | provision-capture-api-insights | provision-secrets | 
provision-storage (parallel) | provision-capture-api-roles-secrets | provision-capture-api-roles-storage

[davidfowl]

cc @eerhardt

[eerhardt]

@mip1983 - I believe this was fixed with

• Fix dependency tracking of resources that write keyvault secrets #12925
• Make app provisioning wait for role assignments and private endpoints #14483

Can you try again with the latest 13.2?

[davidfowl]

Re-open if you can reproduce @mip1983