cloudbuild.yaml 包含不同的云构建器配置

Posted 2023-02-16

【中文标题】cloudbuild.yaml 包含不同的云构建器配置

【英文标题】：cloudbuild.yaml include a different cloud builder configuration

【发布时间】：2019-01-19 01:32:39

【问题描述】：

我的项目被拆分成 gitmodules，如下所示：

/ +
  |
  +-module_1
  |  |
  |  +- cloudbuild.yaml 
  |  +- src/
  |  +-.git/
  | 
  +-module_2
  |  |
  |  +- cloudbuild.yaml 
  |  +- src/
  |  +-.git/
  | 
  +- .git/
  +- .gitmodules
  +- cloudbuild.yaml

我正在尝试从父存储库构建子模块，但 cloudbuild 有一个问题，因为它不会自行获取 gitmodules。因此，当我将 module_1/cloudbuild.yaml 引用为 cloudbuild 配置时，构建失败，因为该文件不存在。我正在考虑可能的解决方法，我想问一下是否可能：

引用/cloudbuild.yaml 作为构建配置 在 cloudbuild.yaml 中添加获取 gitmodules 的步骤 运行不同的 cloudbuild 文件

结果应该类似于：

steps:
  - name: 'gcr.io/$PROJECT_ID/git'
    args: ['submodule', 'update', '--init']
  - name: 'some kind of command that runs cloudbuild.yaml`
    args: ['module_1/cloudbuild.yaml']

免责声明 我知道我可以将所有 cloudbuild 配置放在根存储库中，但我希望模块尽可能自治

【参考方案1】：

我不认为你想要什么是可能的。我不认为这部分可以工作： - name: '某种运行 cloudbuild.yaml 的命令'

最好的办法可能是简单地向我们的issue tracker 提交功能请求，这将允许您直接引用“module_1/cloudbuild.yaml”作为配置。

【讨论】：

如果您运行 gcloud 命令来构建不同的 cloudbuild 会怎样？有没有办法解决这个问题

如果你愿意这样做，那么你就有可能让它发挥作用。您可以尝试在一台机器上运行云构建，然后基本上使用该机器（以及所有必需的库和 cloudbuild.yaml）运行云构建并启动您的真实实例。不过，我不了解您的用例，为什么不简单地将 cloudbuild.yaml 放在不同文件夹的根级别？这比以这种方式（让一个实例启动另一个实例）成本低得多。

您可以在此主题上为Feature Request 加注星标以获取进一步更新，但不提供 ETA 或实施保证。