单仓库(Mono Repo)微服务增量构建最优策略：替代Travis实现按需构建

首先，你提出的Git钩子方案是完全可行的，但在落地时需要注意团队一致性的问题；不过更推荐你直接利用GCP Cloud Build的原生能力来实现增量构建，这样更可靠且不需要依赖本地配置。下面我详细拆解你的问题并给出最优策略：

你的思路是对的：

• 预推送钩子（pre-push）：可以在本地推送代码前，对比当前分支与远程分支的差异，提取出你修改过的微服务目录，然后动态生成对应的cloudbuild.yaml（比如替换其中的构建目标列表）。
• 推送后钩子（post-push）：用来把本地的cloudbuild.yaml重置回原始模板，避免被误提交到仓库，这个逻辑是闭环的。

但这个方案有两个需要注意的点：

1. 团队一致性：所有开发成员都必须配置这个钩子，否则有人没配置的话，推送后还是会触发全量构建。你可以把钩子脚本和模板文件放到仓库里，再写一个简单的安装脚本让大家执行，自动把钩子部署到本地.git/hooks目录。
2. 文件冲突风险：如果cloudbuild.yaml没有被加入.gitignore，很容易被误提交到仓库，导致后续构建逻辑混乱。所以一定要把它加入忽略列表，只保留模板文件（比如cloudbuild.template.yaml）在仓库中。

其实Cloud Build本身就支持在构建过程中动态检测变更目录，不需要修改本地的cloudbuild.yaml，这种方案更可靠，因为所有逻辑在云端执行，不依赖本地配置。具体实现思路如下：

核心逻辑 #

1. 在构建的第一步，用Git工具对比当前提交与基准提交（比如上一次提交、主分支）的差异，提取出变更的微服务目录。
2. 遍历这些目录，只执行对应微服务的构建与推送步骤。

示例配置 #

假设你的微服务都放在根目录的子文件夹中（比如service-a、service-b），可以用这样的cloudbuild.yaml：

steps:
  # 步骤1：拉取完整Git历史并检测变更服务
  - name: 'alpine/git:latest'
    entrypoint: 'bash'
    args:
      - '-c'
      - |
        # 拉取远程分支（如果是对比主分支的话）
        git fetch origin main
        # 提取变更的顶级目录（即微服务文件夹）
        git diff --name-only origin/main $COMMIT_SHA | cut -d'/' -f1 | uniq > /workspace/changed-services.txt
  
  # 步骤2：循环构建并推送变更的微服务
  - name: 'gcr.io/cloud-builders/docker'
    entrypoint: 'bash'
    args:
      - '-c'
      - |
        for service in $(cat /workspace/changed-services.txt); do
          # 确认目录存在（避免误判根目录文件变更）
          if [ -d "$service" ]; then
            echo "Building service: $service"
            docker build -t gcr.io/your-gcp-project/$service ./$service
            docker push gcr.io/your-gcp-project/$service
          fi
        done

substitutions:
  # 利用Cloud Build内置的COMMIT_SHA变量
  _COMMIT_SHA: '${COMMIT_SHA}'

适配不同触发场景 #

• 如果是推送分支触发构建，对比当前提交的父提交即可：git diff --name-only $COMMIT_SHA^ $COMMIT_SHA
• 如果是PR触发构建，对比PR的目标分支（比如origin/main）即可，上面的示例已经覆盖这种情况。

最优策略建议：优先选择Cloud Build原生方案，因为它不需要依赖本地环境，更适合团队协作场景，而且维护成本更低。如果你的场景有特殊需求（比如必须在本地提前确认构建范围），再考虑Git钩子方案，同时一定要做好钩子的分发和版本控制。

1. 确保每个微服务的构建逻辑是独立的，比如每个服务有自己的Dockerfile或构建脚本，这样才能单独触发构建。
2. 可以给每个微服务的构建步骤添加标签，方便在Cloud Build控制台查看哪些服务被构建了。
3. 如果需要更精细的变更检测（比如只构建修改了源码的服务，忽略文档等非代码文件），可以在git diff后过滤掉不需要的文件类型，比如：

   git diff --name-only origin/main $COMMIT_SHA | grep -v '\.md$' | cut -d'/' -f1 | uniq
   

内容的提问来源于stack exchange，提问作者tensai