Undeployable ARM Template generated

[afscrome]

Bicep version Bicep CLI version 0.4.613 (d826ce8411)

Describe the bug The below template compiles successfully, but fails at deployment time with the error "The template function 'reference' is not expected at this location".

This feels like either a code generation issue, or something that should be caught by the type system and produce a compilation error.

To Reproduce

param webAppName string

resource webApp 'Microsoft.Web/sites@2021-01-01' existing = {
  name: webAppName

  resource scmCreds 'basicPublishingCredentialsPolicies' = {
    name: 'scm'
    location: webApp.location
    properties: {
      allow: false
    }
  }
}

Error

{
  "error": {
    "code": "InvalidTemplate",
    "message": "Deployment template validation failed: 'The template resource 'REDACTED/scm' at line '13' and column '5' is not valid: The template function 'reference' is not expected at this location. Please see https://aka.ms/arm-template-expressions for usage details.. Please see https: //aka.ms/arm-template-expressions for usage details.'.",
    "additionalInfo": [
      {
        "type": "TemplateViolation",
        "info": {
          "lineNumber": 13,
          "linePosition": 5,
          "path": "properties.template.resources[0]"
        }
      }
    ]
  }
}

Additional context There is a type issue with the location property for basicPublishingCredentialsPolicies being missing in the type definitions, so this could be a knock on error from that

[alex-frankel]

Interesting, I remember we fixed an error when doing runtime references for top level properties because this is not allowed, so I think you are right this is because location is not in the type definition. If I try this with a resource with a known location property, I get an error:

resource webApp 'Microsoft.Web/sites@2021-01-01' existing = {
  name: webAppName
}

resource foo 'Microsoft.Storage/storageAccounts@2021-04-01' = {
  name: 'foobar'
  location: webApp.location
  sku: {
    name: 'Premium_LRS'
  }
  kind: 'BlobStorage'
}

Are you sure the location property for this basicPublishingCredentialsPolicies is not being ignored? Can you see what happens if you intentionally use a hardcoded location that is different that the parent resource?

[afscrome]

@alex-frankel If location isn't specified, then the deployment fails, but it does appear that as long as you provide a value (even if that value is not a valid azure location e.g. BLAHBLAHBLAH), then the deployment proceeds.

Error if location isn't specified:

{
  "code": "DeploymentFailed",
  "message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.",
  "details": [
    {
      "message": "The parameter location has an invalid value."
    }
  ]
}

The following deploys successfully:

  resource scmCreds 'basicPublishingCredentialsPolicies' = {
    name: 'scm'
    location: 'BLAHBLAHBLAH'
    properties: {
      allow: false
    }
  }

[alex-frankel]

Ah, lovely :)

@seligj95 - can you take a look at this one? Seems like a bug in the API implementation.

[alex-frankel]

@anthony-c-martin / @shenglol -- separately, do we have a bug in our validation of allowed usage of runtime properties? Seems like if a known top level property is not declared in swagger, we don't do that validation.

[seligj95]

@alex-frankel - Will open a ticket with the engineering team. I'm getting the same error.

[shenglol]

@anthony-c-martin / @shenglol -- separately, do we have a bug in our validation of allowed usage of runtime properties? Seems like if a known top level property is not declared in swagger, we don't do that validation.

You are right. Because the location property is not in the type definition, we will skill deploy-time constant validation for it. I feel like we would still run the validation in this case.

[alex-frankel]

The bug for validating location on the Web RP side has been identified and is tracked with this internal work item.

Separately, we should still resolved the validation bug on the bicep side.