.cloudyaml中使用与不使用images属性的差异（推送至Artifact Registry）

先看你提到的示例配置：

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
images: ['gcr.io/myproject/myimage']

一、使用与不使用images属性的核心区别 #

• 配置images属性时：Cloud Build会自动推送构建好的镜像到指定的Artifact Registry（或Container Registry），无需在steps中额外添加docker push命令。
• 不配置images属性时：Cloud Build仅完成镜像构建操作，不会自动推送镜像；若需要推送，必须在steps里手动添加docker push步骤。

二、images属性是否会触发Artifact Registry镜像更新？ #

是的。只要images中指定的镜像路径对应Artifact Registry的仓库，Cloud Build在构建完成后会自动将新镜像推送到该仓库，同标签的现有镜像会被覆盖，相当于完成了镜像更新。

三、不使用images属性会发生什么？ #

• 构建过程本身不会失败，仅停留在“构建出镜像”环节，镜像仅存在于Cloud Build的临时构建环境中，构建结束后环境销毁，镜像也会随之消失。
• 如果你的需求只是验证构建是否能成功，不配置该属性完全可行。
• 但如果目标是将镜像推送到Artifact Registry，既不配置images又未添加手动推送步骤，构建结束后无法获取成品镜像。

四、关于文档示例不一致的困惑 #

文档中提到“不添加images属性构建会失败”的场景，大概率是针对某些需要输出镜像的特定构建模板或集成场景；但绝大多数常规构建场景下，不配置images不会导致失败。那些未包含images的示例，要么仅需验证构建过程，要么已在steps中手动编写了docker push命令，因此无需依赖images属性的自动推送功能。

内容的提问来源于stack exchange，提问作者Alex