Avm Tf Process

AVM Terraform Contribution Process

Use the current AVM process and specification pages from https://azure.github.io/Azure-Verified-Modules/llms.txt. Older public setup pages or module repositories may still contain the retired launcher, Makefile, container, or Porch flow.

1. Confirm classification and ownership

Determine whether the work is a resource, pattern, or utility module. Confirm the approved module name and ownership from the AVM indexes and proposal rather than inventing a name.

Before creating or restructuring a repository, read the current requirements for:

• repository naming and visibility;
• owner and AVM team permissions;
• CODEOWNERS;
• branch protection and required checks;
• issue and pull request templates;
• release and publishing; and
• support lifecycle.

2. Establish the managed repository baseline

Start from the current AVM Terraform template or governance-managed repository state. Import Avm.Authoring and synchronize managed files:

Install-PSResource -Name Avm.Authoring -Repository PSGallery -TrustRepository
Import-Module Avm.Authoring
avm version
avm sync

Review synchronized changes before continuing. Do not restore files from the retired Make, Porch, or container workflow.

3. Implement from current specifications

Build every new resource-deploying module repository on AzAPI. Do not declare or configure hashicorp/azurerm, and do not create any azurerm_* resource or data source for control-plane operations, convenience, or ordinary supporting infrastructure in implementation, submodules, examples, E2E configurations, Terraform tests, fixtures, setup or teardown Terraform, migration examples, documentation examples, or generated snippets.

When supporting configuration needs a direct Azure resource that the module under test does not supply, use an AzAPI resource, data source, or action. Each standalone Terraform root that performs direct Azure operations includes Azure/azapi in required_providers.

Permit hashicorp/azurerm ~> 4.0 only when required by an independently justified azurerm_* resource or data-source block. Each block scopes to one specific unsupported data-plane/non-ARM operation, documents the exact block and why AzAPI cannot implement it with an upstream AzAPI issue or pull request, and is replaced when support ships. Prefer an AVM TFLint override file, but use a justified line-level annotation when it avoids suppressing unrelated findings in the same scope. One valid block does not authorize another. Examples and tests may configure AzureRM only to exercise such blocks. Follow avm-tf-tflint.

Fetch llms.txt, then read each applicable raw spec page. At minimum, review:

• module classification and composition rules;
• TFFR3-TFFR8 for AzAPI;
• TFRMFR1 and TFNFR38 for parent and resource IDs;
• TFRMNFR1 and TFRMNFR2 for submodules and resource labels;
• TFNFR39 for file layout;
• standard interfaces and telemetry;
• tests and examples;
• documentation; and
• semantic versioning and breaking changes.

Use the local specialized skills for implementation details, but resolve any conflict in favor of the current published spec.

4. Develop on a focused branch

Keep changes scoped and preserve unrelated history. Add or update:

• Terraform implementation and exact types;
• root and submodule tests;
• representative examples;
• _header.md and _footer.md;
• migration or upgrade-path coverage when state or addresses change; and
• generated README files through Avm.Authoring.

Scripts and lifecycle hooks must be PowerShell. Supported hook names include:

• tests/unit/setup.ps1;
• tests/integration/setup.ps1;
• examples/<name>/pre.ps1;
• examples/<name>/post.ps1; and
• examples/<name>/tflint-pre.ps1.

Do not add shell-hook counterparts.