23

GitHub 的Google Cloud Build 集成未检测到cloudbuild.yamlDockerfile不在存储库的根目录中。

当使用包含多个的 monorepo 时cloudbuild.yamls,如何配置 GitHub 的 Google Cloud Build 集成以检测正确的cloudbuild.yaml

文件路径:

services/api/cloudbuild.yaml
services/nginx/cloudbuild.yaml
services/websocket/cloudbuild.yaml

Cloud Build 集成输出:

构建失败

4

3 回答 3

36

您可以通过一个步骤cloudbuild.yaml在存储库的根目录中添加 a 来完成此操作gcr.io/cloud-builders/gcloud。此步骤应:

  1. 遍历每个子目录或用于find查找其他cloudbuild.yaml文件。
  2. 对于每个找到cloudbuild.yaml的,通过运行 fork 并提交一个构建gcloud builds submit
  3. 等待所有分叉的gcloud命令完成。

repo的根目录cloudbuild.yamlGoogleCloudPlatform/cloud-builders-community有一个很好的例子。

如果我们去掉非必要的部分,基本上你有这样的东西:

steps:
- name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    for d in */; do
      config="${d}cloudbuild.yaml"
      if [[ ! -f "${config}" ]]; then
        continue
      fi

      echo "Building $d ... "
      (
        gcloud builds submit $d --config=${config}
      ) &
    done
    wait
于 2018-10-19T14:35:27.933 回答
6

我们现在正在迁移到单一存储库,我还没有找到任何可以很好地处理这个问题的 CI/CD 解决方案。

关键是不仅要检测更改,还要检测依赖于该更改的任何服务。这是我们正在做的事情:

  • 要求每个服务都有一个带有构建命令的 MAKEFILE。
  • 将 cloudbuild.yaml 放在 mono repo 的根目录
  • 然后我们使用这个小工具(旧但似乎仍然有效)运行自定义构建步骤https://github.com/jharlap/affected列出了所有包已更改以及依赖于这些包的所有包等。
  • 然后 shell 脚本将make build在受更改影响的任何服务上运行。

到目前为止它运行良好,但我完全理解这是否不适合您的工作流程。

许多人使用的另一个选择是 Bazel。不是最简单的工具,但如果您有多种不同的语言或跨单存储库构建流程,则尤其有用。

于 2018-10-07T04:00:39.990 回答
-3

您可以为存储库创建构建触发器。使用构建配置设置触发器时cloudbuild.yaml,您需要提供cloudbuild.yaml存储库内的路径。

于 2018-09-14T14:49:37.773 回答