【问题标题】:cloudbuild.yaml include a different cloud builder configurationcloudbuild.yaml 包含不同的云构建器配置
【发布时间】: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 配置时,构建失败,因为该文件不存在。我正在考虑可能的解决方法,我想问一下是否可能:

  1. 引用/cloudbuild.yaml 作为构建配置
  2. 在 cloudbuild.yaml 中添加获取 gitmodules 的步骤
  3. 运行不同的 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 配置放在根存储库中,但我希望模块尽可能自治

【问题讨论】:

    标签: git google-app-engine google-cloud-platform git-submodules google-cloud-build


    【解决方案1】:

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

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

    【讨论】:

    • 如果您运行 gcloud 命令来构建不同的 cloudbuild 会怎样?有没有办法解决这个问题
    • 如果你愿意这样做,那么你就有可能让它发挥作用。您可以尝试在一台机器上运行云构建,然后基本上使用该机器(以及所有必需的库和 cloudbuild.yaml)运行云构建并启动您的真实实例。不过,我不了解您的用例,为什么不简单地将 cloudbuild.yaml 放在不同文件夹的根级别?这比以这种方式(让一个实例启动另一个实例)成本低得多。
    • 您可以在此主题上为Feature Request 加注星标以获取进一步更新,但不提供 ETA 或实施保证。
    猜你喜欢
    • 2020-03-27
    • 2012-06-27
    • 2021-03-21
    • 2014-02-05
    • 2016-08-16
    • 2015-09-17
    • 2020-03-04
    • 1970-01-01
    • 2017-10-08
    相关资源
    最近更新 更多