Azure Verified Modules
Glossary GitHub GitHub Issues Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

TFNFR27 - Provider Declarations in Modules

ID: TFNFR27 - Category: Code Style - Provider Declarations in Modules

By rules , in the module code provider MUST NOT be declared. The only exception is when the module indeed need different instances of the same kind of provider(Eg. manipulating resources across different locations or accounts), you MUST declare configuration_aliases in terraform.required_providers. See details in this document .

Read full article gdoc_arrow_right_alt

TFNFR3 - GitHub Repo Branch Protection

ID: TFNFR3 - Category: Contribution/Support - GitHub Repo Branch Protection

Module owners MUST set a branch protection policy on their GitHub Repositories for AVM modules against their default branch, typically main, to do the following:

  1. Requires a Pull Request before merging
  2. Require approval of the most recent reviewable push
  3. Dismiss stale pull request approvals when new commits are pushed
  4. Require linear history
  5. Prevents force pushes
  6. Not allow deletions
  7. Require CODEOWNERS review
  8. Do not allow bypassing the above settings
  9. Above settings MUST also be enforced to administrators
If you use the template repository as mentioned in the contribution guide, the above will automatically be set.

TFNFR30 - Handling Deprecated Outputs

ID: TFNFR30 - Category: Code Style - Handling Deprecated Outputs

Sometimes we notice that the name of certain output is not appropriate anymore, however, since we have to ensure forward compatibility in the same major version, its name MUST NOT be changed directly. It MUST be moved to an independent deprecated_outputs.tf file, then redefine a new output in output.tf and make sure it’s compatible everywhere else in the module.

Read full article gdoc_arrow_right_alt

TFNFR31 - locals.tf for Locals Only

ID: TFNFR31 - Category: Code Style - locals.tf for Locals Only

In locals.tf, file we could declare multiple locals blocks, but only locals blocks are allowed.

You MAY declare locals blocks next to a resource block or data block for some advanced scenarios, like making a fake module to execute some light-weight tests aimed at the expressions.

Read full article gdoc_arrow_right_alt

TFNFR32 - Alphabetical Local Arrangement

ID: TFNFR32 - Category: Code Style - Alphabetical Local Arrangement

Expressions in locals block MUST be arranged alphabetically.

Good examples:

locals {
  name = coalesce(var.name, "name")
  tags = merge(var.tags, {
    env = "prod"
  })
}
locals {
  tags = merge(var.tags, {
    env = "prod"
  })
}

locals {
  name = coalesce(var.name, "name")
}

TFNFR35 - Reviewing Potential Breaking Changes

ID: TFNFR35 - Category: Code Style - Reviewing Potential Breaking Changes

Potential breaking(surprise) changes introduced by resource block

  1. Adding a new resource without count or for_each for conditional creation, or creating by default
  2. Adding a new argument assignment with a value other than the default value provided by the provider’s schema
  3. Adding a new nested block without making it dynamic or omitting it by default
  4. Renaming a resource block without one or more corresponding moved blocks
  5. Change resource’s count to for_each, or vice versa

Terraform moved block could be your cure.

Read full article gdoc_arrow_right_alt

TFNFR36 - Setting prevent_deletion_if_contains_resources

ID: TFNFR36 - Category: Code Style - Setting prevent_deletion_if_contains_resources

From Terraform AzureRM 3.0, the default value of prevent_deletion_if_contains_resources in provider block is true. This will lead to an unstable test because the test subscription has some policies applied, and they will add some extra resources during the run, which can cause failures during destroy of resource groups.

Read full article gdoc_arrow_right_alt