1.4.6.1. 保持流水线脚本的全局统一

在大规模 Terraform 模块治理中，最核心的难题之一就是如何保持所有模块仓库的验证、格式化、测试等流程完全一致。设想一下，如果有几十、上百个模块，每个仓库都维护自己的一套流水线脚本，一旦需要改进某个流程（比如引入新的 lint 工具、升级 terraform-docs 版本），就要挨个模块更新，这是几乎不可能高效完成的任务。

Azure Verified Modules（AVM）采用了一种非常高效的集中式解决方案：每个模块仓库都拥有一个极简的 Makefile，它会在执行时自动从中央仓库拉取最新的 avmmakefile，实现了流水线脚本的集中式管理。

1.4.6.1.1. 模块仓库的 Makefile

每个模块仓库的 Makefile 如下：

SHELL := /bin/bash

$(shell curl -H 'Cache-Control: no-cache, no-store' -sSL "https://raw.githubusercontent.com/Azure/tfmod-scaffold/main/avmmakefile" -o avmmakefile)
-include avmmakefile

这段代码做了两件事：

动态拉取 avmmakefile：只要执行 make，都会从中央仓库下载最新版 avmmakefile。
引用 avmmakefile：然后把它的内容作为当前模块的 make 任务来使用。

这意味着模块仓库本地几乎不用维护任何复杂的脚本逻辑，而是完全依赖 avmmakefile 提供的实现。

1.4.6.1.2. avmmakefile：共享的工具库

avmmakefile 定义了模块维护的常用任务，如 fmt、lint、docs、test 等。这些任务大多是通过 curl 动态执行远程脚本的。例如：

.PHONY: docscheck
docscheck:
    curl -H 'Cache-Control: no-cache, no-store' -sSL "$(REMOTE_SCRIPT)/docs-check.sh" | bash

所以当你运行 make docscheck 时，实际上调用的是中央仓库的 docs-check.sh，并始终获取它的最新版本。

1.4.6.1.3. 为什么这样做？

这种设计的核心优势是：

集中维护：只需要在中央仓库更新一次，所有模块的逻辑立即生效。
保持一致性：所有模块始终使用相同的标准工具链和流程。
轻量仓库：模块仓库不需要携带大量脚本文件，结构简单清晰。
即时修复：一旦发现问题或需要新增功能，可以快速集中修复，无需在每个模块单独更新。

1.4.6.1.4. 目前的限制与缺点

虽然这种方案在大规模治理中带来了巨大的便利，但它也存在一些潜在的限制和缺点：

对外部依赖高度敏感：这一方案严重依赖 GitHub 的可用性。如果 GitHub 出现服务中断，或者中央仓库不可用，所有模块的 make 执行都会失败。
执行时延迟：每次 make 都会触发远程拉取，如果网络较慢，开发体验会打折扣，尤其是频繁执行任务时。
本地开发离线问题：这种模式不适合无网络环境下的开发。若在离线环境中执行 make，将无法下载必要的脚本，导致开发流程中断。

1.4.6.1.5. 小结

总体来看，这是一种高度工程化的实践，它解决了模块治理的标准化、集中化和自动更新的问题，非常适合中大型团队使用。然而，它也带来了一些工程上的权衡，特别是网络依赖和版本控制策略，需要团队根据实际情况加以管理。

保持流水线脚本的全局统一