如何在多个GitHub项目间共享带参数的cloudbuild.yaml？

我已经实现了GitHub提交触发Google Cloud Build，但手上有多个基于Maven和Spring Boot的GitHub仓库，每个仓库的cloudbuild.yaml内容高度重复——构建步骤完全一致，仅Jar文件名和镜像名称不同。比如项目A和B的配置如下：

项目A的cloudbuild.yaml

steps:
  - name: maven:3.8.6-eclipse-temurin-17-alpine
    entrypoint: mvn
    args: [ 'test' ]
  - name: maven:3.8.6-eclipse-temurin-17-alpine
    entrypoint: mvn
    args: [ 'package', '-Dmaven.test.skip=true' ]
  - name: gcr.io/cloud-builders/docker
    args: [ "build", "-t", "europe-west1-docker.pkg.dev/projectname/repo/project-a", "--build-arg=JAR_FILE=target/project-a.jar", "." ]
images: [ "europe-west1-docker.pkg.dev/projectname/repo/project-a" ]

项目B的cloudbuild.yaml

steps:
  - name: maven:3.8.6-eclipse-temurin-17-alpine
    entrypoint: mvn
    args: [ 'test' ]
  - name: maven:3.8.6-eclipse-temurin-17-alpine
    entrypoint: mvn
    args: [ 'package', '-Dmaven.test.skip=true' ]
  - name: gcr.io/cloud-builders/docker
    args: [ "build", "-t", "europe-west1-docker.pkg.dev/projectname/repo/project-b", "--build-arg=JAR_FILE=target/project-b.jar", "." ]
images: [ "europe-west1-docker.pkg.dev/projectname/repo/project-b" ]

如果有上百个这类项目，后续修改构建步骤会带来巨大的维护负担。我设想做一个共享模板文件上传到GCS，每个项目的cloudbuild.yaml仅传递参数引用该模板，请问Google Cloud Build是否支持这种功能？该如何实现构建步骤复用？推荐的方案是什么？

Google Cloud Build支持构建配置的复用，以下是几种符合需求的实现方案，按推荐优先级排序：

1. 模板导入+自定义替换变量（最匹配你的设想） #

Cloud Build原生支持从GCS导入构建配置模板，结合自定义替换变量实现参数化复用，步骤如下：

步骤1：准备并上传模板文件 #

将通用构建逻辑写成模板，注意使用Cloud Build规范的自定义变量格式（变量名以_开头），保存为cloudbuild-template.yaml：

steps:
  - name: maven:3.8.6-eclipse-temurin-17-alpine
    entrypoint: mvn
    args: [ 'test' ]
  - name: maven:3.8.6-eclipse-temurin-17-alpine
    entrypoint: mvn
    args: [ 'package', '-Dmaven.test.skip=true' ]
  - name: gcr.io/cloud-builders/docker
    args: [ "build", "-t", "europe-west1-docker.pkg.dev/projectname/repo/${_PROJECT_NAME}", "--build-arg=JAR_FILE=target/${_PROJECT_NAME}.jar", "." ]
images: [ "europe-west1-docker.pkg.dev/projectname/repo/${_PROJECT_NAME}" ]

将该文件上传到GCS存储桶，例如gs://my-build-bucket/cloudbuild-template.yaml，并确保Cloud Build服务账号拥有该存储桶的storage.objects.get权限。

步骤2：项目侧配置简化的cloudbuild.yaml #

每个项目的cloudbuild.yaml无需编写完整步骤，仅需通过顶级字段imports引用模板，并通过substitutions传递自定义参数：

imports:
  - path: gs://my-build-bucket/cloudbuild-template.yaml
substitutions:
  _PROJECT_NAME: project-a  # 项目B替换为project-b

注意：imports是顶级字段，不能嵌套在steps内；自定义变量必须以_开头，避免与Cloud Build内置变量（如${PROJECT_ID}）冲突。

2. 封装自定义构建器 #

如果构建逻辑更复杂（比如需要额外的预处理/后处理步骤），可以将通用的Maven测试、打包、镜像构建逻辑封装成自定义构建器镜像，然后每个项目的配置直接调用该构建器：

步骤1：构建自定义构建器 #

编写Dockerfile定义构建器的环境和逻辑，构建后推送到你的容器仓库（比如Artifact Registry）。

步骤2：项目侧简化配置 #

每个项目的cloudbuild.yaml只需调用自定义构建器并传递项目名称参数：

steps:
  - name: europe-west1-docker.pkg.dev/projectname/repo/custom-maven-builder
    args: ['project-a']
images: [ "europe-west1-docker.pkg.dev/projectname/repo/project-a" ]

这种方案适合需要统一更新构建工具链或逻辑的场景。

3. 触发器层面配置全局替换变量 #

如果所有项目的差异仅为少数变量，也可以在Cloud Build触发器层面配置全局替换变量，无需每个项目写substitutions：

• 创建触发器时，在「替换变量」中添加_PROJECT_NAME，每个触发器对应一个项目，设置对应的变量值；
• 项目侧的cloudbuild.yaml直接使用${_PROJECT_NAME}变量，无需额外配置。

• 自定义替换变量必须以_开头，这是Cloud Build的强制规范；
• 确保Cloud Build服务账号拥有GCS存储桶的读取权限，否则无法加载模板；
• 模板中可以混合使用自定义变量和Cloud Build内置变量（如${COMMIT_SHA}、${BUILD_ID}），进一步增强灵活性。

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