Only add an explicit dependency on an existing resource when the deployments engine will use the GET response

[jeskew]

Resolves #13674

This PR updates Bicep's resource dependency inference to only record a direct dependency on an existing resource when the deployment will read data from the resource's remote state. In other cases, such as when a template author reads the id or name property or calls a function like listKeys() or getSecret() on the resource, the ResourceDependencyVisitor will instead take a direct dependency on the existing resource's dependencies.

This update will have the effect of only reading the state of existing resources when it is actually used. The ARM backend performs tree shaking on the template and will only create GET jobs for existing resources that are depended on by other resources (whether implicitly or explicitly). There are two observable behavioral differences that result from this:

• A template using language version 2.0 will no longer require /read permissions on an existing resource unless it is actually read. This is particularly useful for KeyVault secret parameters, which require an existing resource and the .getSecret function, as it is not uncommon for a KeyVault to permit usage in ARM deployments but not grant /read permissions to the deploying principal. This causes templates compiled to languageVersion 2.0 to exhibit the same behavior as templates compiled to non-symbolic name templates.
• A template using language version 2.0 can have multiple existing resources pointing to the same resource ID so long as at most one of them is read from. (ARM's tree shaking of existing resources happens before the duplicate check.) There are still some cases where languageVersion: 2.0 behavior will diverge from a non-symbolic name template, but this change will bring their behavior much closer in line with each other. The following is an example of a template that would cause an error in language version 2.0 but raise no issues with a non-symbolic name template:

param saName string

resource sa1 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: saName
  location: resourceGroup().location
  sku: {
    name: 'Standard_GRS'
  }
  kind: 'StorageV2'
}

resource sa2 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: saName
  location: resourceGroup().location
  sku: {
    name: 'Standard_GRS'
  }
  kind: 'StorageV2'
}

output out1 string = sa1.properties.primaryEndpoints.blob
output out2 string = sa2.properties.primaryEndpoints.blob

• Symbolic name users can still force that an existing resource be read and that its existence be checked before a separate resource is deployed by using an explicit dependency. This is an affordance only available in langauge version 2.0:

resource sa1 'Microsoft.Storage/storageAccounts@2023-05-01' existing = {
  name: 'first'
}

resource sa2 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  dependsOn: [
    sa1 // <-- The sa2 deployment won't start unless sa1 exists and is readable. This is a no-op in a non-symbolic name template
  ]
  name: 'second'
  location: resourceGroup().location
  sku: {
    name: 'Standard_GRS'
  }
  kind: 'StorageV2'
}

Microsoft Reviewers: Open in CodeFlow

[github-actions]

Test this change out locally with the following install scripts (Action run 11634323158)

VSCode

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-vsix.sh) --run-id 11634323158

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-vsix.ps1) } -RunId 11634323158"

Azure CLI

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-cli.sh) --run-id 11634323158

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-cli.ps1) } -RunId 11634323158"

[github-actions]

Dotnet Test Results

    72 files   -     36      72 suites   - 36   28m 58s ⏱️ - 15m 52s
11 391 tests  -     13  11 391 ✅  -     13  0 💤 ±0  0 ❌ ±0 
26 513 runs   - 13 216  26 513 ✅  - 13 216  0 💤 ±0  0 ❌ ±0 

Results for commit 909f351. ± Comparison against base commit 74733c6.

♻️ This comment has been updated with latest results.

[shenglol]

LGTM!