Spurious no unnecessary dependsOn entries lint error in 0.32.4

[Ilia-Kosenkov]

Hello! Recent bicep update brought in some changes, and it affected our deployment templates -- we started to get lint errors in a place where previously it was not raised. We deploy Azure Functions and their infrastructure, and our scenario can be dumbed down to the following bicep pieces:

param functionAppName string

module functionAppDeployment 'customRegistryFunctionApp' = {
  name: 'functionAppDeployment'
  params: {
    functionAppName: functionAppName
    // blah blah
  }
}

// Later in the file

module functionAppSettingsDeployment 'customRegistryFunctionAppConfig' = {
  name: 'functionAppSettingsDeployment'
  params: {
    functionAppName: functionAppName
    // blah blah
  }
  // We add `dependsOn` because we need this to deploy *after* function app itself
  // As of 0.32.4 we get `no-unnecessary-dependson` here
  dependsOn: [functionAppDeployment]
}

// customRegistryFunctionApp.bicep
param functionAppName string

resource functionApp 'Microsoft.Web/sites@2023-01-01' = {
  name: functionAppName
  // blah blah
}

// customRegistryFunctionAppConfig.bicep

param functionAppName string

resource existingFunctionApp 'Microsoft.Web/sites@2023-01-01' existing = {
  name: functionAppName
}

resource functionAppSettings 'Microsoft.Web/sites/config@2023-01-01' = {
  parent: existingFunctionApp
  name: 'appsettings'
  // blah blah
}

My question is, will functionAppSettingsDeployment correctly resolve its dependencies by name providing we reference function app deployed within functionAppDeployment as an existing resource?

[jeskew]

Does the functionAppSettingsDeployment declaration contain any references to functionAppDeployment? For example:

param functionAppName string

module functionAppDeployment 'customRegistryFunctionApp' = {
  name: 'functionAppDeployment'
  params: {
    functionAppName: functionAppName
    // blah blah
  }
}

// Later in the file

module functionAppSettingsDeployment 'customRegistryFunctionAppConfig' = {
  name: 'functionAppSettingsDeployment'
  params: {
    functionAppName: functionAppName
    foo: functionAppDeployment.outputs.foo
    // blah blah
  }
}

If so, Bicep will automatically infer a dependency and include a dependsOn property in the compiled template.

[Ilia-Kosenkov]

Weirdly, I do not get this warning when modules are local. But in production both funcApp and appSettings are pulled from private container registry, and there I get a warning (which we treat as error).

main.bicep

param functionAppName string

module functionAppDeployment 'funcApp.bicep' = {
  name: 'functionAppDeployment'
  params: {
    functionAppName: functionAppName
  }
}

module functionAppSettingsDeployment 'appSettings.bicep' = {
  name: 'functionAppSettingsDeployment'
  params: {
    functionAppName: functionAppName
  }

  // Lint error when modules are pulled from container registry
  dependsOn: [ functionAppDeployment ]
}

funcApp.bicep

param functionAppName string

resource functionApp 'Microsoft.Web/sites@2023-01-01' = {
  name: functionAppName
  location: resourceGroup().location
}

appSettings.bicep

param functionAppName string

resource existingFunctionApp 'Microsoft.Web/sites@2023-01-01' existing = {
  name: functionAppName
}

resource functionAppSettings 'Microsoft.Web/sites/config@2023-01-01' = {
  parent: existingFunctionApp
  name: 'appsettings'
}

[jeskew]

In the original example, you indicated that both module statements had additional parameters. What were they?

Bicep's dependency inference is based on any reference to another module/resource, not just outputs. For example, in the following template:

param functionAppName string

module functionAppDeployment 'mod.bicep' = {
  name: 'functionAppDeployment'
  params: {
    functionAppName: functionAppName
  }
}

module functionAppSettingsDeployment 'mod.bicep' = {
  name: 'functionAppSettingsDeployment'
  params: {
    functionAppName: functionAppName
    otherModuleName: functionAppDeployment.name
  }
  dependsOn: [ functionAppDeployment ]
}

A dependency is inferred from line 14 (otherModuleName: functionAppDeployment.name), and the compiled template will reflect this via "dependsOn" whether or not the dependsOn: [ functionAppDeployment ] line is present in Bicep. That is why the linter warns that the dependsOn is unnecessary, since it is not changing the compiled artifact. With that line removed from the Bicep, the compiled JSON will still have an explicit dependency:

{
  ...
  "resources": [
    {
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2022-09-01",
      "name": "functionAppDeployment",
      "properties": {...}
    },
    {
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2022-09-01",
      "name": "functionAppSettingsDeployment",
      "properties": {...},
      "dependsOn": [
        "[resourceId('Microsoft.Resources/deployments', 'functionAppDeployment')]"
      ]
    }
  ]
}

[Ilia-Kosenkov]

(Sorry had to delete partially formatted message). You are right, I missed a transitive dependency. I did not use module outputs in my example, here are updated modules that raise the linting error & they closely reproduce the structure of our production templates. I assume bicep is smart enough to resolve indirect dependencies over multiple modules, right?

main.bicep

param functionAppName string
param storageAccountName string

module functionAppDeployment 'funcApp.bicep' = {
  name: 'functionAppDeployment'
  params: {
    functionAppName: functionAppName
  }
}

module storageDeployment 'storageRole.bicep' = {
  name: 'storageDeployment'
  params: {
    principalId: functionAppDeployment.outputs.principalId
    storageAccountName: storageAccountName
  }
}

module functionAppSettingsDeployment 'appSettings.bicep' = {
  name: 'functionAppSettingsDeployment'
  params: {
    functionAppName: functionAppName
    uri: storageDeployment.outputs.tableServiceUri
  }
  // Now there is a linter warning
  dependsOn: [ functionAppDeployment ]
}

funcApp.bicep

param functionAppName string

resource functionApp 'Microsoft.Web/sites@2023-01-01' = {
  name: functionAppName
  location: resourceGroup().location
}

output principalId string = functionApp.identity.principalId

storageRole.bicep

param principalId string
param storageAccountName string

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}
resource roleDefinition 'Microsoft.Authorization/roleDefinitions@2022-04-01' existing = {
  name: 'Some role id'
}

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(principalId, storageAccountName)
  scope: storageAccount
  properties: {
    principalId: principalId
    roleDefinitionId: roleDefinition.id
  }
}

output tableServiceUri string = storageAccount.properties.primaryEndpoints.table

appSettings.bicep

param functionAppName string
param uri string

resource existingFunctionApp 'Microsoft.Web/sites@2023-01-01' existing = {
  name: functionAppName
}

resource functionAppSettings 'Microsoft.Web/sites/config@2023-01-01' = {
  parent: existingFunctionApp
  name: 'appsettings'
  properties: {
    StorageUri: uri
  }
}

[jeskew]

I assume bicep is smart enough to resolve indirect dependencies over multiple modules, right?

Right. This analysis has been in place for resources since the early days of Bicep, but it was only enabled for modules in v0.32. With the dependsOn removed from main.bicep, in the compiled template, functionAppSettingsDeployment still depends on storageDeployment, which in turn depends on functionAppDeployment.

[Ilia-Kosenkov]

Perfect! Thank you for explaining @jeskew