为什么这两个命令的Google Cloud构建会以不同的方式运行？

问题描述

我们运行这两个命令（第一个是异步的，另一个是同步运行的）

#async BUT does something funky and doesn't run the Dockerfile image as-is
gcloud alpha builds triggers run staging-deploy --branch master

# sync BUT runs the image the way it's supposed to run!!!
gcloud builds submit --config cloudbuild.yaml

两个都在使用我们的cloudbuild.yaml

steps:
- name: gcr.io/$PROJECT_ID/continuous-deploy
  args: ['${_SERVICE}','${_DOWNLOAD_URL}']
  timeout: 1000s
substitutions:
    _SERVICE: none
    _DOWNLOAD_URL: none
timeout: 1100s

我们的Dockerfile非常简单

FROM gcr.io/google.com/cloudsdktool/cloud-sdk:alpine

RUN mkdir -p ./monobuild
COPY . ./monobuild/
WORKDIR "/monobuild"
#NOTE: This file in google cloud build trigger MUST be in root of monorepo BUT I don't know why
#NOTE: This command receives any arguments to docker
#ie. for "docker run {image} {args}",it receives the args
ENTRYPOINT ["./downloadAndExtract.sh"]

所以，当我运行SECOND命令时，它完全遵循Dockerfile使用docker映像。当我运行第一个命令时，它会忽略所有Dockerfile内容，并尝试在git repo中运行脚本（这非常令人沮丧，不是我想要的）。

我们有此目录结构

- gitroot
   - stagingDeploy
        - Dockerfile
        - deployStaging.sh # part of Dockerfile
        - cloudbuild.yaml
   - prodDeploy
        - Dockerfile
        - prodDeploy.sh #part of Docker file
        - cloudbuild.yaml

当然，只有第二个命令适用于此目录结构。第一个命令无法找到deployStaging.sh，直到我们从gitrepo根目录开始-s stagingDeploy / deployStaging.sh，并且大约有5个部署目录，现在git repo根目录已被完全污染。

至少可以说这很令人沮丧，我们不确定如何清理此问题，因此prodDeploy包含所有prod部署脚本和登台脚本，这些登台脚本并删除所有根文件。

当然，我们现在已经损坏了git repo目录结构，在根目录中有来自不同构建版本的大量文件（有时会偶然冲突，因为文件有时会获得相同的名称）。

编辑：在Twitter的配置上分享的内容并不多，因为每个人都只指向yaml文件

谢谢， 院长

解决方法

暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！

如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。

小编邮箱:dio#foxmail.com (将#修改为@）