如何解决为什么这两个命令的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 举报,一经查实,本站将立刻删除。