Eliminate old API versions in your Azure Bicep templates

Introduction

Eliminate old API versions in your Azure Bicep templates – did you know we can leverage the linting features within the bicepconfig.json file to notify you when old ARM API versions are detected? It can be a great addition to your Azure Bicep repository to ensure all cloud engineers can keep track of older API versions that potentially need to be updated. You can even specify the age length before you get a linting warning.

In this quick blog post I’ll detail how to set this up and what it looks like on triggering.

Setup

If you don’t have a bicepconfig.json file you can use this guide provided by the Microsoft Learn documentation here which covers everything you need to know and how to get set up. It should be placed into your repository root.

Below is an example file, you’ll notice at the very bottom I have a use-recent-api-versions property with a value of 0. The 0 value is just enforcing that I should get a linting warning if I am not using the latest available API version – this will show the latest non-preview version or preview if that is the only newer version available.

For your use case the AgeInDays value can be tweaked to suit your needs.

{
  "analyzers": {
    "core": {
      "enabled": true,
      "rules": {
        "adminusername-should-not-be-literal": {
          "level": "warning"
        },
        "artifacts-parameters": {
          "level": "warning"
        },
        "decompiler-cleanup": {
          "level": "warning"
        },
        "explicit-values-for-loc-params": {
          "level": "warning"
        },
        "max-asserts": {
          "level": "warning"
        },
        "max-outputs": {
          "level": "warning"
        },
        "max-params": {
          "level": "warning"
        },
        "max-resources": {
          "level": "warning"
        },
        "max-variables": {
          "level": "warning"
        },
        "nested-deployment-template-scoping": {
          "level": "error"
        },
        "no-conflicting-metadata": {
          "level": "warning"
        },
        "no-deployments-resources": {
          "level": "warning"
        },
        "no-hardcoded-env-urls": {
          "level": "warning"
        },
        "no-hardcoded-location": {
          "level": "warning"
        },
        "no-loc-expr-outside-params": {
          "level": "warning"
        },
        "no-unnecessary-dependson": {
          "level": "warning"
        },
        "no-unused-existing-resources": {
          "level": "warning"
        },
        "no-unused-params": {
          "level": "warning"
        },
        "no-unused-vars": {
          "level": "warning"
        },
        "outputs-should-not-contain-secrets": {
          "level": "warning"
        },
        "prefer-interpolation": {
          "level": "warning"
        },
        "prefer-unquoted-property-names": {
          "level": "warning"
        },
        "protect-commandtoexecute-secrets": {
          "level": "warning"
        },
        "secure-parameter-default": {
          "level": "warning"
        },
        "secure-params-in-nested-deploy": {
          "level": "warning"
        },
        "secure-secrets-in-params": {
          "level": "warning"
        },
        "simplify-interpolation": {
          "level": "warning"
        },
        "simplify-json-null": {
          "level": "warning"
        },
        "use-parent-property": {
          "level": "warning"
        },
        "use-recent-api-versions": {
          "level": "warning",
          "maxAllowedAgeInDays": 0
        }
      }
    }
  }
}

In action – old API versions in Azure Bicep

Here’s an example of how the above file would act in action for your Azure Bicep resources.

Repository integration

By adding a standardised bicepconfig.json file to your git repository we’re able to get a consistent linting experience for all engineers who will be working on the repository. This has two main benefits in my opinion:

• Standardised linting warnings/errors in VSCode across the Teams for that repository Bicep project
• Keeps the engineers informed on old APIs in use so they can decide if it needs to be updated to accommodate newer features & configurations
• Enforcing other coding standards and practices agreed by the team

Conclusion

That’s all there really is to this one, it’s quite a simple quality of life enhancement addition to your Bicep toolkit to keep you informed on older API versions. There may well be good reasons to shy from using the absolute latest, as it may include previews, but I think it can do no harm being aware that a certain resource is using an API version years old.

I have had issues in the past where a newer API version has enabled me to configure newer resource properties from this, so I definitely see the value in integrating this.

What’s your thoughts, are you using this? Do you have a set AgeInDays value to guard against stable API releases? Drop me a comment to let me know.

Further reading:

Linter settings for Bicep config – Azure Resource Manager | Microsoft Learn

Bicep config file – Azure Resource Manager | Microsoft Learn