Using latest api version of a resource

[stan-sz]

In ARM template it's possible to not hardcode the API version for a given resource but dynamically (at 'run time') detect the latest api available for a resource:

"variables": {
    "acrApiVersion": "[first(providers('Microsoft.ContainerRegistry', 'registries/taskRuns').apiVersions)]"
},
resources": [
    {
      "type": "Microsoft.ContainerRegistry/registries/taskRuns",
      "apiVersion": "[variables('acrApiVersion')]",
      ...
    }
]

(note - the ordering is not guaranteed and sorting is not available, thus the first() not necessarily returns the latest available, usually it does)

In bicep this is not possible:

resource promoteRegistryTask 'Microsoft.ContainerRegistry/registries/taskRuns@${first(providers('Microsoft.ContainerRegistry', 'registries/taskRuns')).apiVersions}' = {

Error BCP047: String interpolation is unsupported for specifying the resource type.
Error BCP062: The referenced declaration with name "promoteRegistryTask" is not valid.

Can such scenario be supported in bicep? Is this something ARM template disallows by-design?

[anthony-c-martin]

Thanks for raising this! We have #622 which is similar, but I don't think covers the ability to get the 'latest' at runtime.

Some things to point out about API versioning in ARM:

• API version is not a property of a resource - it defines the contract for interacting with a resource. Generally if you haven't changed any of the properties you supply, the effect on the underlying resource state will be identical between the older and newer version, unless the newer API contract has a breaking change (next point). Although it can feel odd to be using a very old API version, there is usually no great need to update unless for example you need to access some new properties added to a newer version.
• Teams are permitted to make breaking changes to the structure of the API contract between API versions. They are not permitted to make breaking changes to the structure of the API contract for an existing API version. This may mean that if you upgrade versions without changing the structure of your request, you run the risk of being unexpectedly broken at deploy time.
• Without having a known API version at authoring time, we cannot provide a great editor experience (type validation, intellisense etc), as we cannot know what properties are available.

So generally, our feeling on this is that we want to discourage people from picking up the API version at runtime and instead encourage pinning to a version and making the explicit decision to upgrade. That being said, we definitely see the need to simplify the syntax, know whether you're on the latest, and have an easy path to upgrade if you're not and want to be - currently we're thinking of addressing this with #622.

Does that make sense for your use case?

[alex-frankel]

@stan-sz - any thoughts on the above? otherwise, I think we will plan to close this one

[stan-sz]

Thanks for the thorough explanation, @anthony-c-martin.

[stan-sz]

For reference, https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/test-cases#use-hardcoded-api-version

[stan-sz]

Also related to #516