Error provisioning Function App via Bicep - linuxFxVersion is invalid

[mcollier]

Attempting to provision a Function App on Container App via Azure Bicep results in a linuxFxVersion is invalid. The linuxFxVersion value should be in the format DOCKER|<IMAGE_URI> error message.

The linuxFxVersion value set in the Bicep file is: linuxFxVersion: 'Docker|${containerRegistry.properties.loginServer}/ratings-api:latest'

The error occurs when attempting to use the Bicep file via Azure CLI or GitHub Workflow.

Environment

• Bicep CLI version 0.17.1 (d423d61882)
• Azure CLI version 2.48.1
• GitHub Action: azure/arm-deploy@v1

Error message

Error: ERROR: ***"code": "InvalidTemplateDeployment", "message": "The template deployment 'ratings-api-func-app' is not valid according to the validation procedure. The tracking id is '6d69ea7e-82e3-416c-9b62-67741b8e8de9'. See inner errors for details."***

Inner Errors: 
***"code": "ValidationForResourceFailed", "message": "Validation failed for a resource. Check 'Error.Details[0]' for more information."***

Inner Errors: 
***"code": "ValidationForResourceFailed", "message": "Validate resource '/subscriptions/***/resourceGroups/***/providers/Microsoft.Web/sites/csedad-ratings-api' failed with exception 'Code: BadRequest, ExtendedCode: linuxFxVersion is invalid.  The linuxFxVersion value should be in the format DOCKER|<IMAGE_URI>, Message: 51021'"***

Azure Bicep Sample

param location string = resourceGroup().location

@description('Resource name prefix')
param resourceNamePrefix string
var envResourceNamePrefix = toLower(resourceNamePrefix)

resource azStorageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' existing = {
  name: '${envResourceNamePrefix}storage'
}
var azStorageConnectionString = 'DefaultEndpointsProtocol=https;AccountName=${azStorageAccount.name};EndpointSuffix=${az.environment().suffixes.storage};AccountKey=${azStorageAccount.listKeys().keys[0].value}'

resource appInsights 'Microsoft.Insights/components@2020-02-02' existing = {
  name: '${envResourceNamePrefix}-ai'
}

resource environment 'Microsoft.App/managedEnvironments@2022-10-01' existing = {
  name: '${envResourceNamePrefix}-env'
}

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2022-02-01-preview' existing = {
  name: '${envResourceNamePrefix}acr'
}

resource ratingsAPI 'Microsoft.Web/sites@2022-09-01' = {
  name: '${envResourceNamePrefix}-ratings-api'
  location: location
  kind: 'functionapp'
  properties: {
    name: '${envResourceNamePrefix}-ratings-api'
    managedEnvironmentId: environment.id

    siteConfig: {
      linuxFxVersion: 'Docker|${containerRegistry.properties.loginServer}/ratings-api:latest'
      appSettings: [
        {
          name: 'AzureWebJobsStorage'
          value: azStorageConnectionString
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsights.properties.ConnectionString
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_URL'
          value: containerRegistry.properties.loginServer
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_USERNAME'
          value: containerRegistry.listCredentials().username
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_PASSWORD'
          value: containerRegistry.listCredentials().passwords[0].value
        }
      ]
    }
  }
}

output loginServerName string = containerRegistry.properties.loginServer

[mcollier]

@stuartleeks FYI

[mcollier]

It seems that hardcoding the registry name works, but using Docker|${containerRegistry.properties.loginServer}/ratings-api:latest does not.

Interestingly, providing the registry name as an input parameter (of the Bicep template) and then using it like linuxFxVersion: 'Docker|${containerRegistryName}/ratings-api:latest' also works. The end result should be the same. Odd.

[stuartleeks]

Also, once the function app has been deployed using the hard-coded image name, reverting back to the substituted form (Docker|${containerRegistry.properties.loginServer}/ratings-api:latest) works fine!

[stuartleeks]

I encountered essentially the same issue a couple of weeks ago on Container Apps. I see that there is an issue tracking that here

[jainharsh98]

This is currently by design. There are some validations on linuxfxversion before actual creation of resource(preflight) - During validation stage of bicep(which is before creation of all resources) since the container registry does not exist yet the linuxfxversion is not populated correctly and the validations fail. // @lpapudippu @vishal1997