Automated Update of API versions in Bicep templates, reasonable?

[J0F3]

Hi Bicep Team

I have a question about a Bicep related feature I have just discovered in Mend Renovate (tool for automated dependency updates, similar to Dependabot):
https://docs.renovatebot.com/bicep/
renovatebot/renovate#17484

I am asking because I am a bit concerned about the feature they have implemented there. Correct me if I am wrong but as far I am aware it is not very good practice to always update the API versions in existing Bicep (and ARM) templates only to have just the latest version referenced in the template. But that is exactly what the renovate tools it trying to achieve with that feature.

Unfortunately I could also not find a clear statement in Bicep documentation what the best practices with the API versions in Bicep actually is or what is recommended.
I only found the following section in the "old" ARM template documentation: https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/best-practices#api-version

So is it still the idea to continue to use the same API version in a template/deployment until the deployment needs to be changed anyway and a feature of a new API version is really needed? Or has that also changed a bit since the ARM template days?

Thx!
Jonas

[brwilkinson]

Hi @J0F3 that document link you sent is accurate. The guidance is equal for Bicep as ARM json.

In fact they removed to ability to have dynamic variables in Bicep by using a parameter. To encourage static api versions.

adding the two paragraphs from the docs.

• Set the apiVersion property to a hard-coded API version for the resource type. When creating a new template, we recommend you use the latest API version for a resource type. To determine available values, see template reference.

• When your template works as expected, we recommend you continue using the same API version. By using the same API version, you don't have to worry about breaking changes that might be introduced in later versions.

Also like you mentioned, if you need new features then consider updating the API version at that time. Test deploy to test new features and for any breaking changes.

[J0F3]

Hi @brwilkinson

Excellent. That answers my questions perfectly. Thank you very much!

So I will probably suggest to the guys from Renovate to make the automatically update of API versions in Bicep file optionally (by default disabled).

[kilasuit]

As Bicep transpiles to ARM almost all of the best practices, like this one on api version is one I personally would stick with, for production environments
Nothing stopping you having a dedicated workflow that publishes dev and test templates that auto increment when new API versions come about, however that's a lot of work, depending on the resource being deployed.

So it it still the idea to continue to use a same API version in a template/deployment until the deployment needs to be changed anyway and a feature of a new API version is really needed? Or has that also changed a bit since the ARM template days?

This I think is a case of where many orgs are much more likely to stick to a tried and tested progressional advancement strategy than just running on latest api version all the time for everything, but I could be wrong

[gevaertw]

@brwilkinson

While I understand the guidance it would be grate to have the option to use the latest version for an api. Something like

'Microsoft.Network/virtualNetworks/subnets@latest' = {}

Would be great. I just wasted something like 3 hours because somewhere hidden I was using an old API.

[J0F3]

Would you like to elaborate a bit more what exactly problem you had with the older API version? I am eager to know because this is something that actually should not happened and may be bug in the resource provider or so.

In contraire the idea is that you only need to update the API version if you really want to use a new feature which was introduced in a newer API version. So IMHO @latest is something that is definitely not desirable because if you do not touch you code it should just continue to work and with something like @latest this would not be the case anymore.

Therefore I would be interested in what problem you have encountered while keeping older API version in you existing template.

[gevaertw]

In this case it was about adding network rules to a storage account. I no longer have the exact errors but I believe it was in this section:

 resource storageAccountNFS_R 'Microsoft.Storage/storageAccounts@2023-01-01' = {
//some other stuff here
virtualNetworkRules: [
        {
          action: 'Allow'
          id: cycleCloudSN_R.id
        }

If I recall it I was using a 2021 api version, after only changing the API version the error disappeared (well actually I have another one now :p)

Last week I had a similar experience with something on subnets, but I cannot provide more details on that one, as that is gone...

Maybe some additional context, lots of my code is generated using Github Copilot..