Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

构建配置文件架构

构建配置文件包含 Cloud Build 根据您的规范执行任务的说明。例如，您的构建配置文件可以包含构建、打包和推送 Docker 映像的说明。

本页面介绍了 Cloud Build 构建配置文件的架构。如需了解如何创建和使用构建配置文件，请参阅创建基本的构建配置文件。

构建配置文件的结构

构建配置文件使用 Cloud Build API 的 Build 资源进行建模。

您可以使用 YAML 或 JSON 语法编写构建配置文件。如果您使用第三方 http 工具（如 curl）提交构建请求，请使用 JSON 语法。

构建配置文件的结构如下：

YAML

steps:
- name: string
  args: [string, string, ...]
  env: [string, string, ...]
  allowFailure: boolean
  allowExitCodes: [string (int64 format), string (int64 format), ...]
  dir: string
  id: string
  waitFor: [string, string, ...]
  entrypoint: string
  secretEnv: string
  volumes: object(Volume)
  timeout: string (Duration format)
  script: string
  automapSubstitutions: boolean
  results: object(Results)
- name: string
  ...
- name: string
  ...
timeout: string (Duration format)
queueTtl: string (Duration format)
logsBucket: string
options:
 env: [string, string, ...]
 secretEnv: string
 volumes: object(Volume)
 sourceProvenanceHash: enum(HashType)
 machineType: enum(MachineType)
 diskSizeGb: string (int64 format)
 substitutionOption: enum(SubstitutionOption)
 dynamicSubstitutions: boolean
 automapSubstitutions: boolean
 logStreamingOption: enum(LogStreamingOption)
 logging: enum(LoggingMode)
 defaultLogsBucketBehavior: enum(DefaultLogsBucketBehavior)
 pool: object(PoolOption)
 pubsubTopic: string
 requestedVerifyOption: enum(RequestedVerifyOption)
 workerRelease: string
substitutions: map (key: string, value: string)
tags: [string, string, ...]
serviceAccount: string
secrets: object(Secret)
availableSecrets: object(Secrets)
artifacts: object(Artifacts)
  goModules: [object(GoModules), ...]
  mavenArtifacts: [object(MavenArtifact), ...]
  pythonPackages: [object(PythonPackage), ...]
  npmPackages: [object(npmPackage), ...]
images:
- [string, string, ...]

JSON

{
    "steps": [
    {
        "name": "string",
        "args": [
            "string",
            "string",
            "..."
        ],
        "env": [
            "string",
            "string",
            "..."
        ],
        "allowFailure": "boolean",
        "allowExitCodes: [
            "string (int64 format)",
            "string (int64 format)",
            "..."
        ],
        "dir": "string",
        "id": "string",
        "waitFor": [
            "string",
            "string",
            "..."
        ],
        "entrypoint": "string",
        "secretEnv": "string",
        "volumes": "object(Volume)",
        "timeout": "string (Duration format)",
        "script" : "string",
        "automapSubstitutions" : "boolean",
        "results": "object(Results)"
    },
    {
        "name": "string"
        ...
    },
    {
        "name": "string"
        ...
    }
    ],
    "timeout": "string (Duration format)",
    "queueTtl": "string (Duration format)",
    "logsBucket": "string",
    "options": {
        "sourceProvenanceHash": "enum(HashType)",
        "machineType": "enum(MachineType)",
        "diskSizeGb": "string (int64 format)",
        "substitutionOption": "enum(SubstitutionOption)",
        "dynamicSubstitutions": "boolean",
        "automapSubstitutions": "boolean",
        "logStreamingOption": "enum(LogStreamingOption)",
        "logging": "enum(LoggingMode)",
        "defaultLogsBucketBehavior": "enum(DefaultLogsBucketBehavior)"
        "env": [
            "string",
            "string",
            "..."
        ],
        "secretEnv": "string",
        "volumes": "object(Volume)",
        "pool": "object(PoolOption)",
        "pubsubTopic: string",
        "requestedVerifyOption": "enum(RequestedVerifyOption)",
        "workerRelease": "string"
    },
    "substitutions": "map (key: string, value: string)",
    "tags": [
        "string",
        "string",
        "..."
    ],
    "serviceAccount": "string",
    "secrets": "object(Secret)",
    "availableSecrets": "object(Secrets)",
    "artifacts": "object(Artifacts)",
      "goModules": [object(GoModules), ...],
      "mavenArtifacts": ["object(MavenArtifact)", ...],
      "pythonPackages": ["object(PythonPackage)", ...],
      "npmPackages": ["object(npmPackage)", ...],
    "images": [
        "string",
        "string",
        "..."
    ]
}

构建配置文件的每个部分都定义了您想要 Cloud Build 执行的任务的一部分：

构建步骤

构建步骤指定您想要 Cloud Build 执行的操作。对于每个构建步骤，Cloud Build 都会将 docker 容器作为 docker run 的实例执行。构建步骤类似于脚本中的命令，便于您在构建中灵活执行任意指令。如果您可以将构建工具打包到容器中，则 Cloud Build 可将构建工具作为构建的一部分执行。默认情况下，Cloud Build 会在同一机器上顺序执行所有构建步骤。如果您有可以并发运行的步骤，请使用 waitFor 选项。

您最多可以在配置文件中添加 300 个构建步骤。

使用构建配置文件中的 steps 字段可以指定一个构建步骤。以下代码段展示了您可以在 steps 字段中设置的配置类型：

YAML

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/mydepl', 'my-image=gcr.io/my-project/myimage']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-east4-b'
  - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project-id/myimage', '.']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/kubectl",
        "args": [
            "set",
            "image"
            "deployment/mydepl"
            "my-image=gcr.io/my-project/myimage"
        ],
        "env": [
            "CLOUDSDK_COMPUTE_ZONE=us-east4-b",
            "CLOUDSDK_CONTAINER_CLUSTER=my-cluster"
        ]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/my-project-id/myimage",
            "."
        ]
    }
    ]
}

`name`

使用构建步骤的 name 字段来指定 Cloud Builder，这是一种运行常见工具的容器映像。您可以在构建步骤中使用构建器来执行任务。

以下代码段展示了调用 bazel、gcloud 和 docker 构建器的构建步骤：

YAML

steps:
- name: 'gcr.io/cloud-builders/bazel'
...

- name: 'gcr.io/cloud-builders/gcloud'
...

- name: 'gcr.io/cloud-builders/docker'
...

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/bazel"
        ...
    },
    {
        "name": "gcr.io/cloud-builders/gcloud"
        ...
    },
    {
        "name": "gcr.io/cloud-builders/docker"
        ...
    }
    ]
}

`args`

构建步骤的 args 字段获取一个参数列表，并将其传递给 name 字段引用的构建器。传递给构建器的参数会传递给在构建器中运行的工具，这样您就可以调用该工具支持的任何命令。如果构建步骤中使用的构建器具有入口点，则 args 将用作该入口点的参数。如果构建器未定义入口点，则 args 中的第一个元素将用作入口点，其余元素将用作参数。

每个步骤最多可以创建 100 个参数。参数长度上限为 10,000 个字符。

以下代码段调用 docker build 命令并安装 Maven 依赖项：

YAML

steps:
- name: 'gcr.io/cloud-builders/mvn'
  args: ['install']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project-id/myimage', '.']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/mvn",
        "args": [
            "install"
        ]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/my-project-id/myimage",
            "."
        ]
    }
    ]
}

`env`

构建步骤的 env 字段获取一个环境变量列表，这些环境变量将在运行该步骤时使用。变量的格式为 KEY=VALUE。

在以下构建配置中，构建步骤的 env 字段会在执行 kubectl 之前设置 Compute Engine 地区和 GKE 集群：

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/myimage', 'frontend=gcr.io/myproject/myimage']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-east1-b'
  - 'CLOUDSDK_CONTAINER_CLUSTER=node-example-cluster'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    },
    {
        "name": "gcr.io/cloud-builders/kubectl",
        "args": [
            "set",
            "image",
            "deployment/myimage",
            "frontend=gcr.io/myproject/myimage"
        ],
        "env": [
            "CLOUDSDK_COMPUTE_ZONE=us-east1-b",
            "CLOUDSDK_CONTAINER_CLUSTER=node-example-cluster"
        ]
    }
    ]
}

`allowFailure`

在构建步骤中，如果您将 allowFailure 字段的值设置为 true，并且该构建步骤失败，则只要该构建中的所有其他构建步骤都成功，构建就会成功。

如果 build 中的所有构建步骤都将 allowFailure 设置为 true，并且所有构建步骤都失败，则 build 的状态仍为 Successful。

allowExitCodes 的优先级高于此字段。

以下代码段允许在第一步失败时成功构建：

YAML

steps:
- name: 'ubuntu'
  args: [ '-c', 'exit 1']
  allowFailure: true
- name: 'ubuntu'
  args: ['echo', 'Hello World']

JSON

{
  "steps": [
    {
        "name": "ubuntu",
        "args": [
            "-c",
            "exit -1"
        ],
        "allowFailure": true,
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "Hello World"
        ]
    }
  ]
}

`allowExitCodes`

使用 allowExitCodes 字段指定当构建步骤返回特定退出代码时，可以忽略该步骤的失败。

如果构建步骤失败，且退出代码与您在 allowExitCodes 中提供的值匹配，则 Cloud Build 将允许此构建步骤失败，而不会导致整个构建失败。

如果 100% 的构建步骤都失败，但每个步骤都以您在 allowExitCodes 字段中指定的代码退出，则构建仍然成功。

但是，如果构建步骤失败，并且生成了另一个退出代码（与您在 allowExitCodes 中指定的值不匹配），则整个构建将失败。

与您的 build 相关的退出代码取决于您的软件。例如，“1”是 Linux 中的常见退出代码。您还可以在脚本中定义自己的退出代码。allowExitCodes 字段接受最大值为 255 的数字。

此字段的优先级高于 allowFailure。

以下代码段允许在第一步失败并返回其中一个提供的退出代码时成功完成构建：

YAML

steps:
- name: 'ubuntu'
  args: ['-c', 'exit 1']
  allowExitCodes: [1]
- name: 'ubuntu'
  args: ['echo', 'Hello World']

JSON

{
  "steps": [
    {
        "name": "ubuntu",
        "args": [
            "-c",
            "exit 1"
        ],
        "allowExitCodes": [1],
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "Hello World"
        ]
    }
  ]
}

`dir`

在构建步骤中使用 dir 字段设置运行该步骤的容器时使用的工作目录。如果您在构建步骤中设置了 dir 字段，则工作目录会设置为 /workspace/<dir>。如果此值是相对路径，则它相对于构建的工作目录。如果此值是绝对值，则它可能位于构建的工作目录之外，在这种情况下，在构建步骤执行期间，该路径的内容可能不会持久保留（除非指定了该路径的卷）。

以下代码段会将构建步骤的工作目录设置为 /workspace/examples/hello_world：

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
  env: ['PROJECT_ROOT=hello']
  dir: 'examples/hello_world'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ],
        "env": [
            "PROJECT_ROOT=hello"
        ],
        "dir": "examples/hello_world"
    }
    ]
}

ID

使用 id 字段为构建步骤设置唯一标识符。请将 id 与 waitFor 字段一起使用，以配置运行构建步骤的顺序。如需了解如何使用 waitFor 和 id，请参阅配置构建步骤顺序。

`waitFor`

在构建步骤中使用 waitFor 字段指定在运行该构建步骤之前必须运行的步骤。如果没有为 waitFor 提供任何值，则构建步骤将在构建请求中的所有先前构建步骤成功完成后才开始运行。如需了解如何使用 waitFor 和 id，请参阅配置构建步骤顺序。

`entrypoint`

如果您不想使用构建器的默认入口点，请在构建步骤中使用 entrypoint 来指定入口点。如果您未设置此字段，则 Cloud Build 将使用构建器的入口点。以下代码段设置 npm 构建步骤的入口点：

YAML

steps:
- name: 'gcr.io/cloud-builders/npm'
  entrypoint: 'node'
  args: ['--version']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/npm",
        "entrypoint": "node",
        "args": [
            "--version"
        ]
    }
    ]
}

`secretEnv`

这是一个使用 Cloud KMS 加密密钥加密的环境变量列表。必须在构建的密钥中指定这些值。如需了解如何使用此字段，请参阅在构建请求中使用加密变量。

`volumes`

Volume 是一个 Docker 容器卷，它装载到构建步骤中，用于在构建步骤之间持久保存文件。在 Cloud Build 运行构建步骤时，它会自动将一个 workspace 卷装载到 /workspace 中。您可以使用步骤的 volumes 字段指定要装载到构建步骤容器的其他卷。

例如，以下构建配置文件在第一步中将一个文件写入卷，并在第二步中读取。如果这些步骤未将 /persistent_volume 路径指定为永久性卷，则第一个步骤将在该路径上写入文件，然后在执行第二个步骤之前丢弃该文件。如果在两个步骤中为卷指定相同名称，第一个步骤中 /persistent_volume 的内容会持久保留到第二个步骤。

YAML

steps:
- name: 'ubuntu'
  volumes:
  - name: 'vol1'
    path: '/persistent_volume'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
        echo "Hello, world!" > /persistent_volume/file
- name: 'ubuntu'
  volumes:
  - name: 'vol1'
    path: '/persistent_volume'
  args: ['cat', '/persistent_volume/file']

JSON

  {
    "steps": [
      {
        "name": "ubuntu",
        "volumes": [
          {
            "name": "vol1",
            "path": "/persistent_volume"
          }
        ],
        "entrypoint": "bash",
        "args": [
          "-c",
          "echo \"Hello, world!\" > /persistent_volume/file\n"
        ]
      },
      {
        "name": "ubuntu",
        "volumes": [
          {
            "name": "vol1",
            "path": "/persistent_volume"
          }
        ],
        "args": [
          "cat",
          "/persistent_volume/file"
        ]
     }
    ]
  }

`timeout`

在构建步骤中使用 timeout 字段来设置执行步骤的时间限制。如果您未设置此字段，则该步骤会一直运行，直到完成或构建本身超时。构建步骤的 timeout 字段不得超过为构建指定的 timeout 值。

timeout 以秒为单位（使用时长格式），最多包含九个小数位，以 s 结尾（例如：3.5s）。

在以下构建配置中，ubuntu 步骤在 500 秒后超时：

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '600']
  timeout: 500s
- name: 'ubuntu'
  args: ['echo', 'hello world, after 600s']

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "600"
        ],
        "timeout": "500s"
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "hello world, after 600s"
        ]
    }
    ]
}

脚本

在构建步骤中使用 script 字段指定要在该步骤中执行的 shell 脚本。如果您在构建步骤中指定了 script，则无法在同一步骤中指定 args 或 entrypoint。如需了解如何使用 script 字段，请参阅运行 Bash 脚本。

automapSubstitutions

如果设置为 true，则会自动映射所有替换变量，并一步将其作为环境变量提供。如果设置为 false，则忽略该步骤的替换。如需查看示例，请参阅替换变量值。

结果

允许构建步骤存储数据，然后在构建完成后将该数据附加到构建结果中的证明中。存储的数据必须是键值对，其中键是字符串，值是 JSON 对象。结果必须包含以下字段：

name：结果的名称。此名称会显示在构建结果中的证明中。您还可以在构建步骤中使用此名称来引用结果。例如，您可以在同一构建步骤中使用 script 将值附加到结果中。
attestationContent：（可选）证明的名称。此值可以是任何值，并将显示在构建结果中的证明中。仅当您计划验证 build 证明时，才需要此字段。
attestationType：（可选）证明的类型。此值可以是任何值，并将显示在构建结果中的证明中。仅当您计划验证 build 证明时，才需要此字段。

以下 build 使用结果配置来输出证明，以便用户验证该 build 仅使用具有受支持前缀的网址来构建映像。在此示例中，结果定义为 allowlisted_prefixes。接下来，allowlisted_prefixes 会设置为 allowlisted_prefixes 和 [\"github.com\", \"gitlab.com\"] 的键值对，然后作为证明附加到构建结果。

YAML

steps:
- name: "gcr.io/cloud-builders/docker"
  id: "build-step"
  args: ["build", "-t", "us-docker.pkg.dev/my-project/demo/helloworld-image", "."]
- name: "ubuntu"
  id: "check-source-fetch-urls"
  results:
    - name: "allowlisted_prefixes"
      attestationContent: "remote_fetch_allow_list"
      attestationType: "https://cloudbuild.googleapis.com/attestations/build_content_restrictions"
  script: |
    #!/bin/bash
    prefixes="[\"github.com\", \"gitlab.com\"]"
    echo "allowlisted_prefixes=$prefixes" >> $RESULTS
    cat $RESULTS
images:
  - "us-docker.pkg.dev/my-project/demo/helloworld-image"
options:
  requested_verify_option: VERIFIED
  defaultLogsBucketBehavior: REGIONAL_USER_OWNED_BUCKET

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "id": "build-step",
      "args": [
        "build",
        "-t",
        "us-docker.pkg.dev/my-project/demo/helloworld-image",
        "."
      ]
    },
    {
      "name": "ubuntu",
      "id": "check-source-fetch-urls",
      "results": [
        {
          "name": "allowlisted_prefixes",
          "attestationContent": "remote_fetch_allow_list",
          "attestationType": "https://cloudbuild.googleapis.com/attestations/build_content_restrictions"
        }
      ],
      "script": "#!/bin/bash\nprefixes=\"[\\\"github.com\\\", \\\"gitlab.com\\\"]\"\necho \"allowlisted_prefixes=$prefixes\" >> $RESULTS\ncat $RESULTS\n"
    }
  ],
  "images": [
    "us-docker.pkg.dev/my-project/demo/helloworld-image"
  ],
  "options": {
    "requested_verify_option": "VERIFIED",
    "defaultLogsBucketBehavior": "REGIONAL_USER_OWNED_BUCKET"
  }
}

`timeout`

在构建步骤之外使用 timeout 字段可设置执行构建的总体时间限制。如果超过此时间，则构建工作会停止，并且构建状态为 TIMEOUT。

如果未设置 timeout，则构建会使用默认 timeout（60 分钟）。timeout 的最大值为 24 小时。timeout 以秒为单位，使用时长格式，最多包含九个小数位，以 s 结尾（例如：3.5s）。

在以下代码段中，timeout 设置为 660 秒，以避免构建因休眠而超时：

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '600']
timeout: 660s

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "600"
        ]
    }
    ],
    "timeout": "660s"
}

`queueTtl`

使用 queueTtl 字段指定构建可以加入队列的时长。如果构建在队列中的时长超过 queueTtl 中设置的值，则构建会过期，并且构建状态会设置为 EXPIRED。如果未提供任何值，Cloud Build 会使用默认值 3600s（1 小时）。queueTtl从 createTime开始计时。queueTtl 必须以秒为单位指定，最多包含九个小数位，并以“s”结尾，例如 3.5s。

在以下代码段中，timeout 设置为 20s，queueTtl 设置为 10s。 queueTtl 从 createTime（即请求构建的时间）开始计时，timeout 从 startTime（即构建开始的时间）开始计时。因此，除非构建在此之前开始，否则 queueTtl 将在 createTime + 10s 时过期。

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '5']
timeout: 20s
queueTtl: 10s

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "5"
        ]
    }
    ],
    "timeout": "20s",
    "queueTtl": "10s"
}

`logsBucket`

为 build 设置 logsBucket 字段，以指定必须将 build 日志写入其中的 Cloud Storage 存储桶。如果您未设置此字段，Cloud Build 会使用 defaultLogsBucketBehavior 的值将构建日志存储在 Cloud Storage 中由 Cloud Build 创建的存储桶中。

以下代码段将 Cloud Build 设置为将构建日志存储在 Cloud Storage 中的自定义存储桶中。

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
logsBucket: 'gs://mybucket'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ]
    }
    ],
    "logsBucket": "gs://mybucket"
}

`options`

使用字段为您的构建指定以下options可选参数：

enableStructuredLogging：在将构建日志发送到 Logging 时，允许将指定的构建日志字段映射到 LogEntry 字段。例如，如果您的构建日志包含 message，则该消息会显示在生成的日志条目的 textPayload 或 jsonPayload.message 中。无法映射的构建日志字段会显示在日志条目 jsonPayload 中。如需了解详情，请参阅将构建日志字段映射到日志条目字段。

env：将存在于此构建的所有构建步骤中的全局环境变量定义列表。如果同时在全局范围内和构建步骤中定义了变量，则该变量将使用构建步骤值。元素的格式为 KEY=VALUE，表示环境变量 KEY 的值为 VALUE。

secretEnv：使用 Cloud Key Management Service 加密密钥加密的全局环境变量列表，这些变量可供此 build 中的所有 build 步骤使用。您必须在构建的 Secret 中指定这些值。

volumes：要在全局范围内为所有构建步骤装载的卷列表。在开始构建过程之前，每个卷都是作为空卷创建的。构建完成后，系统会舍弃卷及其内容。全局卷名称和路径不能与构建步骤定义的卷冲突。在只有一个步骤的构建中使用全局卷是无效的，因为它意味着构建请求的配置不正确。

pubsubTopic：用于提供 Pub/Sub 主题名称以接收构建状态通知的选项。如果您未提供名称，则 Cloud Build 会使用默认主题名称 cloud-builds。以下代码段指定 Pub/Sub 主题名称为 my-topic：

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
    pubsubTopic: 'projects/my-project/topics/my-topic'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "pubsubTopic": "projects/my-project/topics/my-topic"
    }
}

sourceProvenanceHash：设置 sourceProvenanceHash 选项以指定来源的哈希算法。以下代码段将哈希算法指定为 SHA256：

YAML

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

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "sourceProvenanceHash": ["SHA256"]
    }
}

machineType：Cloud Build 提供四种高 CPU 虚拟机类型来运行您的 build：两种具有 8 个 CPU 的机器类型和两种具有 32 个 CPU 的机器类型。Cloud Build 还提供另外两种虚拟机类型（1 个 CPU 和 2 个 CPU）来运行构建。默认机器类型为 e2-standard-2，具有 2 个 CPU。请求高 CPU 虚拟机可能会增加 build 的启动时间。添加 machineType 选项以请求具有更高 CPU 的虚拟机：

YAML

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

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    },
    ],
    "options": {
        "machineType": "E2_HIGHCPU_8"
    }
}

如需详细了解如何使用 machineType 选项，请参阅加速构建。

diskSizeGb：使用 diskSizeGb 选项为构建请求自定义磁盘大小。您可以请求的大小上限为 4000 GB。

以下代码段请求的磁盘大小为 200 GB：

YAML

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

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "diskSizeGb": '200'
    }
}

logStreamingOption：使用此选项指定是否要将构建日志流式传输到 Cloud Storage。默认情况下，Cloud Build 会在构建完成后收集构建日志；此选项指定您是否要在构建流程中实时流式传输构建日志。以下代码段指定将构建日志流式传输到 Cloud Storage：

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
options:
 logStreamingOption: STREAM_ON

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ]
    }
    ],
    "options": {
        "logStreamingOption": "STREAM_ON"
    }
}

logging：使用此选项可指定是要在 Cloud Logging 还是 Cloud Storage 中存储构建日志：

GCS_ONLY：构建日志会发送到 Cloud Storage 存储桶。
CLOUD_LOGGING_ONLY：构建日志会发送到 Logging 存储桶。
LEGACY：构建日志会发送到这两个位置的存储桶。如果未定义 logging，Cloud Build 会使用此值。
NONE：不存储构建日志。

如需详细了解构建日志存储的优势和注意事项，请参阅构建日志存储选项。

以下代码段指定将构建日志存储在 Cloud Storage 中：

YAML

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

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "logging": "GCS_ONLY"
    }
}

defaultLogsBucketBehavior：

当 logging 配置为将构建日志发送到 Cloud Storage 时，请使用此字段。

当 logging 的值为 GCS_ONLY、Legacy 或未定义时，您的构建日志会发送到 Cloud Storage 中的存储桶。在这种情况下，Cloud Build 会评估 logsBucket 和 defaultLogsBucketBehavior 字段，以确定哪个 Cloud Storage 存储桶接收构建日志：

`logsBucket`	`defaultLogsBucketBehavior`	构建日志的存储位置
已指定存储桶	值已被忽略	在 `logsBucket` 中指定的存储桶中
没有值	`REGIONAL_USER_OWNED_BUCKET`	在 Cloud Build 创建且归用户所有的存储桶中
没有值	`LEGACY_BUCKET`	在 Cloud Build 创建和 Google Cloud拥有的存储桶中
没有值	没有值	在 Cloud Build 创建且归用户所有的存储桶中。如果创建此存储桶失败，则构建日志会存储在由 Cloud Build 创建并由 Google Cloud拥有的存储桶中。

如需了解详情，请参阅构建日志存储选项。

以下 build 配置会将 defaultLogsBucketBehavior 字段设置为值 REGIONAL_USER_OWNED_BUCKET：

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/myproject/myrepo/myimage', '.' ]
options:
  defaultLogsBucketBehavior: REGIONAL_USER_OWNED_BUCKET

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "-t",
        "us-central1-docker.pkg.dev/myproject/myrepo/myimage",
        "."
      ]
    }
    ],
    "options": {
      "defaultLogsBucketBehavior": "REGIONAL_USER_OWNED_BUCKET"
    }
}

dynamicSubstitutions：使用此选项可明确启用或停用替换中的 bash 参数。如果由触发器调用您的构建，则 dynamicSubstitutions 字段始终设置为，无需在构建配置文件中指定。如果是手动调用您的构建，则必须将 dynamicSubstitutions 字段设置为 true，以便在运行构建时解读 bash 参数扩展。

automapSubstitutions：自动将所有替换变量映射到将在整个构建过程中可用的环境变量。如需查看示例，请参阅替换变量值。

substitutionOption：您将设置此选项和下面的 substitutions 字段，以指定当替代变量检查出现错误时采取的行为。

pool：将该字段的值设置为要运行构建的专用池的资源名称。如需了解如何在专用池上运行构建，请参阅在专用池中运行构建。

requestedVerifyOption：将 requestedVerifyOption 的值设置为 VERIFIED，以启用并验证为 build 生成证明和出处元数据。设置后，只有在生成证明和出处时，您的 build 才会被标记为 SUCCESS。

workerRelease：选择发布渠道或特定版本。

以下 build 配置会将 workerRelease 字段设置为常规渠道：

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/myproject/myrepo/myimage', '.' ]
options:
  workerRelease: regular

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "-t",
        "us-central1-docker.pkg.dev/myproject/myrepo/myimage",
        "."
      ]
    }
    ],
    "options": {
      "workerRelease": "regular"
    }
}

以下示例将 workerRelease 字段设置为特定版本：

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/myproject/myrepo/myimage', '.' ]
options:
  workerRelease: 2026.09

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "-t",
        "us-central1-docker.pkg.dev/myproject/myrepo/myimage",
        "."
      ]
    }
    ],
    "options": {
      "workerRelease": "2026.09"
    }
}

`substitutions`

在构建配置文件中使用 substitutions 以在构建时替换特定变量。对于那些直到构建时才知道值的变量，或者使用不同的变量值重用现有构建请求，替代变量很有用。默认情况下，如果缺少替代变量或缺少替换，则构建将返回错误。但您可以使用 ALLOW_LOOSE 选项跳过此检查。

以下代码段使用替代变量来打印“hello world”。ALLOW_LOOSE 替换选项已设置，这意味着如果缺少替代变量或缺少替换，则构建不会返回错误。

YAML

steps:
- name: 'ubuntu'
  args: ['echo', 'hello ${_SUB_VALUE}']
substitutions:
    _SUB_VALUE: world
options:
    substitution_option: 'ALLOW_LOOSE'

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "hello ${_SUB_VALUE}"
        ]
    }
    ],
    "substitutions": {
        "_SUB_VALUE": "world"
},
    "options": {
        "substitution_option": "ALLOW_LOOSE"
    }
}

如需详细了解如何使用 substitutions，请参阅替代变量值。

`tags`

使用 tags 字段将构建分成组，并过滤构建。以下配置设置了名为 mytag1 和 mytag2 的两个标记：

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  ...
- name: 'ubuntu'
  ...
tags: ['mytag1', 'mytag2']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker"
    },
    {
        "name": "ubuntu"
    }
    ],
    "tags": [
        "mytag1",
        "mytag2"
    ]
}

`availableSecrets`

使用此字段可在构建请求中引用 Secret Manager 或 Cloud KMS 中的一个或多个 Secret。Cloud Build 可以使用这些 Secret 在构建流程中执行操作，例如登录账号。

Secret Manager

如需在构建配置文件中使用 Secret Manager Secret，请在构建配置文件的 availableSecrets 字段中添加 secretManager 字段。secretManager 字段包含一对或多对 versionName 和 env 字段：

versionName：Secret Manager 中 Secret 的路径。
env：构建步骤可用于引用 Secret 的本地名称（环境变量）。

构建步骤中的 secretEnv 字段指定了可在该步骤中使用的环境变量。

以下配置展示了如何使用存储在 Secret Manager 中的 Docker 用户名和密码登录 Docker：

YAML

    steps:
    - name: 'gcr.io/cloud-builders/docker'
      entrypoint: 'bash'
      args: ['-c', 'docker login --username=$$USERNAME --password=$$PASSWORD']
      secretEnv: ['USERNAME', 'PASSWORD']
    availableSecrets:
      secretManager:
      - versionName: projects/PROJECT_ID/secrets/DOCKER_PASSWORD_SECRET_NAME/versions/DOCKER_PASSWORD_SECRET_VERSION
        env: 'PASSWORD'
      - versionName: projects/PROJECT_ID/secrets/DOCKER_USERNAME_SECRET_NAME/versions/DOCKER_USERNAME_SECRET_VERSION
        env: 'USERNAME'

JSON

{
  "steps": [
  {
    "name": "gcr.io/cloud-builders/docker",
    "entrypoint": "bash",
    "args": [
      "-c",
      "docker login --username=$$USERNAME --password=$$PASSWORD"
    ],
    "secretEnv": [
      "USERNAME",
      "PASSWORD"
    ]
  }
  ],
  "availableSecrets": {
    "secretManager": [{
      "versionName": "projects/PROJECT_ID/secrets/DOCKER_PASSWORD_SECRET_NAME/versions/DOCKER_PASSWORD_SECRET_VERSION",
      "env": "PASSWORD"
  }, {
    "versionName": "projects/PROJECT_ID/secrets/DOCKER_USERNAME_SECRET_NAME/versions/DOCKER_USERNAME_SECRET_VERSION",
    "env": "USERNAME"
      }]
  }
}

如需了解详情，请参阅使用 Secret。

Cloud KMS

如需在构建配置文件中使用 Cloud KMS 密钥，请在构建配置文件的 availableSecrets 字段中添加 inline 字段。inline 字段包含一个或多个 kmsKeyName 和 envMap 对：

kmsKeyName：Cloud KMS 密钥的路径。
envMap：构建步骤可用于引用 Secret 的本地名称（环境映射）。

构建步骤中的 secretEnv 字段指定了可在该步骤中使用的环境变量。

以下配置展示了如何使用存储在 Cloud KMS 中的 Docker 用户名和密码登录 Docker。

YAML

     steps:
     - name: 'gcr.io/cloud-builders/docker'
       entrypoint: 'bash'
       args: ['-c', 'docker login --username=$$USERNAME --password=$$PASSWORD']
       secretEnv: ['USERNAME', 'PASSWORD']
     - name: 'gcr.io/cloud-builders/docker'
       entrypoint: 'bash'
       args: ['-c', 'docker pull $$USERNAME/IMAGE:TAG']
       secretEnv: ['USERNAME']
     availableSecrets:
       inline:
       - kmsKeyName: projects/PROJECT_ID/locations/global/keyRings/USERNAME_KEYRING_NAME/cryptoKeys/USERNAME_KEY_NAME
         envMap:
           USERNAME: 'ENCRYPTED_USERNAME'
       - kmsKeyName: projects/PROJECT_ID/locations/global/keyRings/PASSWORD_KEYRING_NAME/cryptoKeys/PASSWORD_KEY_NAME
         envMap:
           PASSWORD: 'ENCRYPTED_PASSWORD'

JSON

{
  "steps": [
  {
    "name": "gcr.io/cloud-builders/docker",
    "entrypoint": "bash",
    "args": [
      "-c",
      "docker login --username=$$USERNAME --password=$$PASSWORD"
    ],
    "secretEnv": [
      "USERNAME",
      "PASSWORD"
    ]
  },
  {
    "name": "gcr.io/cloud-builders/docker",
    "entrypoint": "bash",
    "args": [
      "-c",
      "docker pull $$USERNAME/REPOSITORY:TAG"
      ],
      "secretEnv": [
      "USERNAME"
    ]
  }
  ],
  "availableSecrets": {
    "inline": [{
      "kmsKeyName": "projects/PROJECT_ID/locations/global/keyRings/USERNAME_KEYRING_NAME/cryptoKeys/USERNAME_KEY_NAME",
      "envMap": {
        "USERNAME": "ENCRYPTED_USERNAME"
        }
    },
    {
    "kmsKeyName": "projects/PROJECT_ID/locations/global/keyRings/PASSWORD_KEYRING_NAME/cryptoKeys/PASSWORD_KEY_NAME",
    "envMap": {
        "PASSWORD": "ENCRYPTED_PASSWORD"
        }
    }]
  }
}

`secrets`

Secret 将包含加密值的一组 secret 环境变量与用于解密该值的 Cloud KMS 密钥进行配对。

`serviceAccount`

使用此字段指定要在构建时使用的 IAM 服务账号。如需了解详情，请参阅配置用户指定的服务账号。

您无法在此字段中指定旧版 Cloud Build 服务账号。

`images`

构建配置文件中的 images 字段指定 Cloud Build 要推送到 Artifact Registry 的一个或多个 Linux Docker 映像。您可能有一个执行任务而不生成任何 Linux Docker 映像的构建，但如果您构建映像而不将其推送到注册表，则映像会在构建完成时被舍弃。如果在构建期间未生成指定的映像，则构建将失败。如需详细了解如何存储映像，请参阅在 Artifact Registry 中存储制品。

以下构建配置将设置 images 字段以存储构建的映像：

YAML

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

JSON

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

`artifacts`

artifacts 字段指定在所有构建步骤成功完成后要存储在 Cloud Storage 或 Artifact Registry 中的一个或多个工件。

`objects`

在 artifacts 字段中，object 字段指定要存储在 Cloud Storage 中的一个或多个制品。如需了解详情，请参阅在 Cloud Storage 中存储构建工件。

以下构建配置设置了 artifacts 字段，用于将构建的 Go 软件包存储在 gs://mybucket/ 中：

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['build', 'my-package']
artifacts:
  objects:
    location: 'gs://mybucket/'
    paths: ['my-package']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "build",
            "my-package"
        ]
    }
    ],
    "artifacts": {
      "objects": {
        "location": "gs://mybucket/",
        "paths": [
            "my-package"
        ]
      }
    }
}

`goModules`

借助 goModules 字段，您可以将非容器 Go 模块上传到 Artifact Registry 中的 Go 代码库。如需了解详情，请参阅构建和测试 Go 应用。

repository_location 字段指定用于存储软件包的 Artifact Registry 代码库。module_path 字段指定包含要上传的 Go 模块的本地目录。此目录必须包含 go.mod 文件。

我们建议为 module_path 的值使用绝对路径。您可以使用 . 引用当前工作目录，但该字段不能省略或留空。如需详细了解如何使用 module_path，请参阅构建和测试 Go 应用。

以下 build 配置会设置 goModules 字段，以将 example.com/myapp 中的模块上传到 Artifact Registry 代码库 quickstart-go-repo：

YAML

artifacts:
  goModules:
    - repositoryName: 'quickstart-go-repo'
      repositoryLocation: 'us-central1'
      repositoryProjectId: 'argo-local-myname'
      sourcePath: '/workspace/myapp'
      modulePath: 'example.com/myapp'
      moduleVersion: 'v1.0.0'

JSON

{
  "artifacts": {
    "goModules": [
     {
      "repositoryName": "quickstart-go-repo",
      "repositoryLocation": "us-central1",
      "repositoryProjectId": "argo-local-myname",
      "sourcePath": "/workspace/myapp",
      "modulePath": "example.com/myapp",
      "moduleVersion": "v1.0.0"
     }
    ]
  }
}

`mavenArtifacts`

借助 mavenArtifacts 字段，您可以将非容器 Java 工件上传到 Artifact Registry 中的 Maven 代码库。如需了解详情，请参阅构建和测试 Java 应用。

示例：将文件夹中的所有 Maven 文件上传到 Artifact Registry 代码库

以下 build 配置会设置 mavenArtifacts 字段，以将文件夹 /workspace/target/com/mycompany/app/my-app-1/1.0.0/ 中的所有文件上传到 Artifact Registry 代码库 https://us-central1-maven.pkg.dev/my-project-id/my-java-repo：

YAML

artifacts:
  mavenArtifacts:
    - repository: 'https://us-central1-maven.pkg.dev/my-project-id/my-java-repo'
      deployFolder: '/workspace/target'
      artifactId: 'my-app-1'
      groupId: 'com.mycompany.app'
      version: '1.0.0'

JSON

{
  "artifacts": {
    "mavenArtifacts": [
      {
        "repository": "https://us-central1-maven.pkg.dev/my-project-id/my-java-repo",
        "deployFolder": "/workspace/target",
        "artifactId": "my-app-1",
        "groupId": "com.mycompany.app",
        "version": "1.0.0"
      }
    ]
  }
}

如需将 Maven 文件部署到 /workspace/target/com/mycompany/app/my-app-1/1.0.0/，请将 -DaltDeploymentRepository=local::default::file:./workspace/target 选项添加到 Maven 部署命令中。

示例：将打包的 Maven 文件上传到 Artifact Registry 代码库

以下 build 配置设置了 mavenArtifacts 字段，用于将打包的文件 my-app-1.0-SNAPSHOT.jar 上传到 Artifact Registry 代码库 https://us-central1-maven.pkg.dev/my-project-id/my-java-repo：

YAML

artifacts:
  mavenArtifacts:
    - repository: 'https://us-central1-maven.pkg.dev/my-project-id/my-java-repo'
      path: '/workspace/my-app/target/my-app-1.0-SNAPSHOT.jar'
      artifactId: 'my-app-1'
      groupId: 'com.mycompany.app'
      version: '1.0.0'

JSON

{
  "artifacts": {
    "mavenArtifacts": [
      {
        "repository": "https://us-central1-maven.pkg.dev/my-project-id/my-java-repo",
        "path": "/workspace/my-app/target/my-app-1.0-SNAPSHOT.jar",
        "artifactId": "my-app-1",
        "groupId": "com.mycompany.app",
        "version": "1.0.0"
      }
    ]
  }
}

`pythonPackages`

借助 pythonPackages 字段，您可以将 Python 软件包上传到 Artifact Registry。如需了解详情，请参阅构建和测试 Python 应用。

以下 build 配置会设置 pythonPackages 字段，以将 Python 软件包 dist/my-pkg.whl 上传到 Artifact Registry 代码库 https://us-east1-python.pkg.dev/my-project/my-repo：

YAML

artifacts:
  pythonPackages:
   - repository: 'https://us-east1-python.pkg.dev/my-project/my-repo'
     paths: ['dist/my-pkg.whl']

JSON

{
  "artifacts": {
    "pythonPackages": [
      {
        "repository": "https://us-east1-python.pkg.dev/my-project/my-repo",
        "paths": ["dist/my-pkg.whl"]
      }
    ]
  }
}

`npmPackages`

使用 npmPackages 字段配置 Cloud Build，以将构建的 npm 软件包上传到 Artifact Registry 中支持的代码库。您必须为 repository 和 packagePath 提供值。

repository 字段指定用于存储软件包的 Artifact Registry 代码库。packagePath 字段指定包含要上传的 npm 软件包的本地目录。此目录必须包含 package.json 文件。

我们建议为 packagePath 的值使用绝对路径。您可以使用 . 引用当前工作目录，但该字段不能省略或留空。如需详细了解如何使用 npmPackages，请参阅构建和测试 Node.js 应用。

以下构建配置设置 npmPackages 字段，以将 /workspace/my-pkg 目录中的 npm 软件包上传到 Artifact Registry 代码库 https://us-east1-npm.pkg.dev/my-project/my-repo。

YAML

artifacts:
  npmPackages:
   - repository: 'https://us-east1-npm.pkg.dev/my-project/my-repo'
     packagePath: '/workspace/my-pkg'

JSON

{
  "artifacts": {
    "npmPackages": [
      {
        "repository": "https://us-east1-npm.pkg.dev/my-project/my-repo",
        "packagePath": "/workspace/my-pkg"
      }
    ]
  }
}

`oci`

使用 oci 字段配置 Cloud Build，以将 OCI 映像上传到 Artifact Registry 中支持的代码库。您必须为 file 和 registryPath 提供值。

registryPath 字段指定用于存储映像的 Artifact Registry 代码库。file 字段指定包含要上传的 OCI 映像的本地目录。此目录必须包含 OCI 映像文件。

我们建议为 file 的值使用绝对路径。您可以使用 . 引用当前工作目录，但不能省略该字段或将其留空。

以下 build 配置设置了 oci 字段，用于将 /.pack/layout-repo/my-app 目录中的 OCI 映像上传到 Artifact Registry 代码库 https://us-east1-docker.pkg.dev/my-project/my-repo。

YAML

artifacts:
  oci:
  - file: '/.pack/layout-repo/my-app'
    registryPath: 'https://us-east1-docker.pkg.dev/my-project/my-repo'
    tags: ["primary_image"]

JSON

{
  "artifacts": {
    "oci": [
      {
        "file": "/.pack/layout-repo/my-app",
        "registryPath": "https://us-east1-docker.pkg.dev/my-project/my-repo",
        "tags": ["primary_image"]
      }
    ]
  }
}

`genericArtifacts`

使用 genericArtifacts 字段将未指定类型的文件作为新软件包上传到 Artifact Registry 中的通用代码库。如果您要上传通用文件（例如文本文件或二进制文件），或者要上传不受支持的 Artifact Registry 代码库类型的软件包，则此配置非常有用。

folder 字段指定包含要上传到通用代码库的文件的文件夹。registryPath 字段是接收文件夹中文件的 Artifact Registry 通用代码库的地址。

以下 build 配置设置了 genericArtifacts 字段，以将 /workspace/binaryOut 文件夹上传到 Artifact Registry 通用代码库 projects/my-project/locations/us-east1/repositories/my-repo/packages/my-pkg/versions/my-version。

YAML

artifacts:
  genericArtifacts:
  - folder: '/workspace/binaryOut'
    registryPath: 'projects/my-project/locations/us-east1/repositories/my-repo/packages/my-pkg/versions/my-version'

JSON

{
  "artifacts": {
    "genericArtifacts": [
      {
        "folder": "/workspace/binaryOut",
        "registryPath": "projects/my-project/locations/us-east1/repositories/my-repo/packages/my-pkg/versions/my-version"
      }
    ]
  }
}

您可以将通用制品配置为构建依赖项，以便 Cloud Build 在构建开始之前下载依赖项。如需了解详情，请参阅将通用制品指定为依赖项。

使用 Dockerfile

如果您使用的 gcloud CLI 或构建触发器在 Cloud Build 中执行 Docker 构建，则可以使用 Dockerfile，而无需单独的构建配置文件。如果您想要对 Docker 构建进行更多调整，则除了 Dockerfile 之外，您还可以提供 build 配置文件。如需了解如何使用 Dockerfile 来构建 Docker 映像，请参阅快速入门：构建。

Cloud Build 网络

在 Cloud Build 运行每个构建步骤时，它会将相应步骤的容器连接到一个名为 cloudbuild 的本地 Docker 网络。cloudbuild网络托管应用默认凭证 (ADC)， Google Cloud 服务可以使用这些凭证自动查找您的凭证。如果您运行的是嵌套 Docker 容器，并且想要向底层容器公开 ADC，或者在 docker 步骤中使用 gcloud，请在 docker build 步骤中使用 --network 标志：

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '--network=cloudbuild', '.']

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "--network=cloudbuild",
        "."
      ]
   }
  ]
}

后续步骤

了解如何创建基本的构建配置文件，以便为 Cloud Build 配置构建。
请阅读手动启动构建，以了解如何在 Cloud Build 中运行构建。

构建配置文件架构 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

构建配置文件的结构

YAML

JSON

构建步骤

YAML

JSON

name

YAML

JSON

args

YAML

JSON

env

YAML

JSON

allowFailure

YAML

JSON

allowExitCodes

YAML

JSON

dir

YAML

JSON

ID

waitFor

entrypoint

YAML

JSON

secretEnv

volumes

YAML

JSON

timeout

YAML

JSON

脚本

automapSubstitutions

结果

YAML

JSON

timeout

YAML

JSON

queueTtl

YAML

JSON

logsBucket

YAML

JSON

options

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

substitutions

YAML

JSON

tags

YAML

JSON

availableSecrets

YAML

JSON

YAML

构建配置文件架构

`name`

`args`

`env`

`allowFailure`

`allowExitCodes`

`dir`

`waitFor`

`entrypoint`

`secretEnv`

`volumes`

`timeout`

`timeout`

`queueTtl`

`logsBucket`

`options`

`substitutions`

`tags`

`availableSecrets`

`secrets`

`serviceAccount`

`images`

`artifacts`

`objects`

`goModules`

`mavenArtifacts`

`pythonPackages`

`npmPackages`

`oci`

`genericArtifacts`