Você pode especificar a ordem em que as etapas de versão são executadas. Por padrão, as etapas de versão são executadas sequencialmente, mas você pode configurá-las para serem executadas simultaneamente.
Nesta página, explicamos como configurar a ordem das etapas de versão.
Ordem e dependências das etapas de build
Use o campo waitFor
em uma etapa de build para especificar as etapas que precisam ser executadas antes que a etapa de build seja executada. Se nenhum valor for informado para waitFor
, a etapa de build aguardará até que todas as etapas de criação anteriores, que façam parte da solicitação da criação, sejam concluídas com êxito, antes de proceder à execução.
Para executar uma etapa de build imediatamente no momento de build, use -
no campo waitFor
.
A ordem das etapas de build no campo steps
está relacionada à ordem em que as etapas são executadas. As etapas serão executadas em série ou simultaneamente com base nas dependências definidas nos campos waitFor
.
As etapas dependem de cada id
na waitFor
e nenhuma etapa será iniciada até que cada dependência seja concluída.
Etapas sem o campo opcional waitFor
(ou com um campo waitFor
vazio) aguardam a conclusão de todas as etapas anteriores antes de serem executadas. Portanto, se nenhuma etapa tiver id
no campo waitFor
, todas as etapas serão executadas em série na ordem em que estiverem definidas.
As etapas podem depender do início do build se waitFor
tiver apenas -
. Ao declarar que uma etapa depende apenas de -
, a etapa é executada imediatamente no início do build. A primeira etapa definida depende implicitamente do início.
O snippet a seguir mostra uma configuração de versão com duas etapas executadas em série:
YAML
steps:
- name: foo
- name: bar
JSON
{
"steps": [{
"name": "foo"
},
{
"name": "bar"
}
]
}
O snippet a seguir mostra duas etapas simultâneas que dependem do início. A terceira etapa espera as duas primeiras serem concluídas para ser iniciada. Essa versão simultânea executa as etapas A
e B
no início. A terceira etapa esperará implicitamente até que as etapas anteriores sejam concluídas antes de começar. Esse exemplo pode ser simplificado com a omissão dos campos id
, que não são referenciados em um campo waitFor
subsequente.
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"
}
]
}
O snippet a seguir mostra etapas simultâneas que dependem de uma etapa anterior. A etapa A
é executada imediatamente quando a versão é iniciada. As etapas B
e C
, executadas simultaneamente após A
ter sido concluída com sucesso. Observe que os campos id
e waitFor
na etapa B
e o campo id
na etapa C
podem ser omitidos sem alterar a ordem de execução.
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"
]
}
]
}
Exemplos
No exemplo abaixo, as etapas gsutil
e wget
são chamadas simultaneamente.
Depois que essas etapas forem concluídas, a etapa ubuntu
é chamada.
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"
]
}
]
}
O exemplo abaixo usa o campo id
para identificar determinadas etapas de build. Os valores de id
são usados em waitFor
para definir a ordem das etapas de build:
- Primeiro, a etapa
fetch-resources
usagsutil
para copiar os recursos locais do Cloud Storage. Ao mesmo tempo,go
gera, testa e instala o código-fonte. Em seguida, a etapa de build
docker
cria a imagem após a conclusão de todas as outras etapas.
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"
]
}
A seguir
- Configure o Cloud Build para criar, testar e implantar artefatos.
- Saiba como executar versões manualmente e com acionadores.