Validation for apiVersion should be able to look up variables

It can be convenient to use a variable to set an apiVersion that is used in multiple places:

"variables": {
    "storageApiVersion": "2016-01-01"
}

...

"resources": [
  {
    "apiVersion": "[variables('storageApiVersion')]",
    "type": "Microsoft.Storage/storageAccounts",
    "name": "StorageAccountName",
    "location": "West US 2",
  } 
]

...

"diagnosticsStorageAccountConfig": {
  "blobEndpoint": "[reference(concat('Microsoft.Storage/storageAccounts/StorageAccountName/', variables('storageApiVersion')).primaryEndpoints.blob]",
}

It looks like the API version validation is not able to look up the value of the variable and therefore gives a validation error:

Value must be one of the following values: "2015-05-01-preview", "2015-06-15", "2016-01-01", "2017-06-01", "2017-10-01", "2018-02-01", "2018-11-01", "2019-04-01", "2019-06-01", "2018-03-01-preview", "2018-07-01"arm-template (schema)

The validation message contains the value “2016-01-01” indicating that it is indeed a valid value but does not recognize that this is the value of the variable referenced in the apiVersion element.

[StephenWeatherford]

@snorrk Thanks. That is a feature that’s on our list, but is not prioritized yet. Can you verify that we’d only need to handle apiVersion strings with a simple variables(‘xxx’) or parameters(‘xxx’) expression and nothing else in it?

cc @neilpeterson

[StephenWeatherford]

@alexgav This could be done in two ways…

1. The lang server could interpret the expressions itself, looking up variables itself, although that could be problematic with nested templates which have different scope
2. The lang server could send a request to the extension to interpret these expression values.

I’m leaning toward #2, what do you think?