1.4.6.1. Maintaining Global Pipeline Consistency

In large-scale Terraform module governance, one of the core challenges is keeping the validation, formatting, testing, and other processes completely consistent across all module repositories. Imagine maintaining dozens or even hundreds of modules where each repository has its own set of pipeline scripts. If a specific process needs improvement (e.g., introducing a new linting tool or upgrading the terraform-docs version), updating every single module individually becomes a task that is almost impossible to complete efficiently.

Azure Verified Modules (AVM) adopts a highly efficient centralized solution: each module repository possesses a minimalist Makefile, which automatically pulls the latest Makefile from a central repository upon execution, thereby achieving centralized management of pipeline scripts.

1.4.6.1.1. The Makefile in Module Repositories

The Makefile for each module repository looks like this:

SHELL := /bin/bash
AVM_MAKEFILE_REF := main

$(shell curl -H 'Cache-Control: no-cache, no-store' -sSL "https://raw.githubusercontent.com/Azure/avm-terraform-governance/$(AVM_MAKEFILE_REF)/Makefile" -o avmmakefile)
-include avmmakefile

This code performs two actions:

1. Dynamically pulls `avmmakefile: Whenevermakeis executed, it downloads the latest version ofavmmakefile` from the central repository.
2. References `avmmakefile: It then uses the content of that file as themake` tasks for the current module.

This means the module repository requires almost no complex script logic to be maintained locally, relying entirely on the implementation provided by avmmakefile.

1.4.6.1.2. avmmakefile: The Shared Tool Library

The avmmakefile defines common maintenance tasks for modules, such as pre-commit, pr-check, test-examples, etc. Most of these tasks execute remote scripts dynamically via curl. For example:

.PHONY: pr-check
pr-check:
    @echo "Running PR check..."
    porch run ${TUI} -f "$(AVM_PORCH_BASE_URL)/pr-check.porch.yaml?ref=$(AVM_PORCH_REF)"

So, when you run make pr-check, you are effectively calling porch with config from the central repository and always fetching its latest version.

1.4.6.1.3. Why Adopt This Approach?

The core advantages of this design are:

• Centralized Maintenance: You only need to update the central repository once, and the logic takes effect immediately across all modules.
• Consistency: All modules always use the same standard toolchain and processes.
• Lightweight Repositories: Module repositories do not need to carry a large number of script files, keeping the structure simple and clear.
• Instant Fixes: Once an issue is identified or a new feature is needed, it can be fixed centrally and quickly without the need to update each module individually.

1.4.6.1.4. Current Limitations and Drawbacks

While this solution offers immense convenience for large-scale governance, it also presents some potential limitations and drawbacks:

• High Sensitivity to External Dependencies: This approach relies heavily on the availability of GitHub. If GitHub experiences a service outage or the central repository becomes unavailable, make execution will fail for all modules.
• Execution Latency: Every make command triggers a remote pull. If the network connection is slow, the developer experience may be compromised, especially when running tasks frequently.
• Offline Development Issues: This mode is unsuitable for development in environments without network access. If make is executed in an offline environment, the necessary scripts cannot be downloaded, causing the development process to halt.

1.4.6.1.5. Summary

Overall, this is a highly engineered practice that solves the problems of standardization, centralization, and automated updates in module governance, making it very suitable for medium-to-large teams. However, it also introduces engineering trade-offs—particularly regarding network dependencies and version control strategies—that teams need to manage based on their specific circumstances.