您可以指定构建步骤的执行顺序。默认情况下,构建步骤按顺序运行,但您可以将其配置为并发运行。
本页面介绍了如何配置构建步骤的顺序。
构建步骤顺序和依赖项
在构建步骤中使用 waitFor
字段指定在运行该构建步骤之前必须运行的步骤。如果没有为 waitFor
提供任何值,则构建步骤将在构建请求中的所有先前构建步骤成功完成后才开始运行。
如需在构建时立即运行构建步骤,请使用 waitFor
字段中的 -
。
steps
字段中构建步骤的顺序与步骤得到执行的顺序相关。这些步骤将根据在其 waitFor
字段中定义的依赖项依次或并发运行。
步骤何时运行取决于 waitFor
中的每个 id
,并且只在每个依赖项成功完成后才会启动。
没有可选 waitFor
字段(或者 waitFor
为空)的步骤会等到所有前面的步骤成功完成后才得到执行。因此,如果没有 waitFor
字段中包含 id
的步骤,那么所有步骤将按照其定义的顺序依次执行。
通过使 waitFor
仅包含 -
,步骤可以依赖于构建的开始而开始运行。通过将步骤声明为仅依赖于 -
,该步骤会在构建开始时立即运行。定义的第一步隐式依赖于开始。
以下代码段展示了一个构建配置,其中包含两个依次运行的步骤:
YAML
steps:
- name: foo
- name: bar
JSON
{
"steps": [{
"name": "foo"
},
{
"name": "bar"
}
]
}
以下代码段展示了同时依赖于开始的并发步骤;第三步要等到前两步成功完成之后才会启动。此并发构建会在构建开始时运行步骤 A
和 B
。第三步将隐式等待,直到前两个步骤完成之后才开始执行。后续 waitFor
中并不引用 id
字段,省略这些字段可以简化此示例。
YAML
steps:
- name: foo
id: A
- name: bar
id: B
waitFor: ['-']
- name: baz
JSON
{
"steps": [
{
"name": "foo",
"id": "A"
},
{
"name": "bar",
"id": "B",
"waitFor": ["-"]
},
{
"name": "baz"
}
]
}
以下代码段展示了依赖于上一步的并发步骤。步骤 A
在构建开始时立即运行。步骤 A
成功完成后,步骤 B
和 C
并发运行。请注意,步骤 B
中的 id
和 waitFor
字段以及步骤 C
中的 id
字段可以省略,这样并不会改变执行顺序。
YAML
steps:
- name: foo
id: A
- name: bar
id: B
waitFor:
- A
- name: baz
id: C
waitFor:
- A
JSON
{
"steps": [
{
"name": "foo",
"id": "A"
},
{
"name": "bar",
"id": "B",
"waitFor": [
"A"
]
},
{
"name": "baz",
"id": "C",
"waitFor": [
"A"
]
}
]
}
示例
以下示例同时调用了 gsutil
和 wget
步骤。
完成这些步骤后,系统会调用 ubuntu
步骤。
YAML
steps:
# Download the binary and the data in parallel.
- name: 'gcr.io/cloud-builders/wget'
args: ['https://example.com/binary']
- name: 'gcr.io/cloud-builders/gsutil'
args: ['cp', 'gs://$PROJECT_ID-data/rawdata.tgz', '.']
waitFor: ['-'] # The '-' indicates that this step begins immediately.
# Run the binary on the data, once both are downloaded.
- name: 'ubuntu'
args: ['./binary', 'rawdata.tgz']
JSON
{
"steps": [
{
"name": "gcr.io/cloud-builders/wget",
"args": [
"https://example.com/binary"
]
},
{
"name": "gcr.io/cloud-builders/gsutil",
"args": [
"cp",
"gs://$PROJECT_ID-data/rawdata.tgz",
"."
],
"waitFor": [
"-"
]
},
{
"name": "ubuntu",
"args": [
"./binary",
"rawdata.tgz"
]
}
]
}
以下示例使用 id
字段标识某些构建步骤。在 waitFor
中会使用 id
的值来定义构建步骤顺序:
- 首先,
fetch-resources
步骤使用gsutil
从 Cloud Storage 复制本地资源。go
并发生成、测试和安装源代码。 然后,
docker
构建步骤会在所有其他步骤完成之后构建映像。
YAML
steps:
- name: 'gcr.io/cloud-builders/go'
args: ['generate']
- name: 'gcr.io/cloud-builders/go'
args: ['test', './...']
- name: 'gcr.io/cloud-builders/go'
args: ['install', 'mytarget']
id: 'go-install'
- name: 'gcr.io/cloud-builders/gsutil'
args: ['cp', '-r', './somefiles', 'gs://my-resource-bucket/somefiles']
waitFor: ['-'] # The '-' indicates that this step begins immediately.
id: 'fetch-resources'
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/$PROJECT_ID/mytarget', '.']
waitFor: ['go-install', 'fetch-resources']
images: ['gcr.io/$PROJECT_ID/mytarget']
JSON
{
"steps": [
{
"name": "gcr.io/cloud-builders/go",
"args": [
"generate"
]
},
{
"name": "gcr.io/cloud-builders/go",
"args": [
"test",
"./..."
]
},
{
"name": "gcr.io/cloud-builders/go",
"args": [
"install",
"mytarget"
],
"id": "go-install"
},
{
"name": "gcr.io/cloud-builders/gsutil",
"args": [
"cp",
"-r",
"./somefiles",
"gs://my-resource-bucket/somefiles"
],
"waitFor": [
"-"
],
"id": "fetch-resources"
},
{
"name": "gcr.io/cloud-builders/docker",
"args": [
"build",
"-t",
"gcr.io/$PROJECT_ID/mytarget",
"."
],
"waitFor": [
"go-install",
"fetch-resources"
]
}
],
"images": [
"gcr.io/$PROJECT_ID/mytarget"
]
}
后续步骤
- 配置 Cloud Build 以构建、测试和部署工件。
- 了解如何手动运行构建以及如何使用触发器运行构建。