Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
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.
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.
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']
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 usa gsutil 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']
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[[["\u003cp\u003eBuild steps can be configured to run sequentially or concurrently using the \u003ccode\u003ewaitFor\u003c/code\u003e field.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003ewaitFor\u003c/code\u003e field specifies which steps must complete before a given step begins, and an empty \u003ccode\u003ewaitFor\u003c/code\u003e or absence of this field means a step will wait for all prior steps to finish.\u003c/p\u003e\n"],["\u003cp\u003eUsing \u003ccode\u003e-\u003c/code\u003e in the \u003ccode\u003ewaitFor\u003c/code\u003e field will cause a build step to run immediately when the build starts.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eid\u003c/code\u003e field allows you to define a unique identifier for a step, which can then be referenced in other steps' \u003ccode\u003ewaitFor\u003c/code\u003e fields to establish dependencies.\u003c/p\u003e\n"],["\u003cp\u003eIf no \u003ccode\u003eid\u003c/code\u003e values are specified in the \u003ccode\u003ewaitFor\u003c/code\u003e field of any steps, all build steps will run sequentially, in the order they are defined.\u003c/p\u003e\n"]]],[],null,["# Configuring the order of build steps\n\nYou can specify the order in which your build steps are executed. By default,\nbuild steps run sequentially, but you can configure them to run concurrently.\n\nThis page explains how to configure the order of the build steps.\n\n### Build step order and dependencies\n\nUse the `waitFor` field in a build step to specify which steps *must run* before\nthe build step is run. If no values are provided for `waitFor`, the build step\nwaits for *all prior* build steps in the build request to complete successfully\nbefore running.\n\nTo run a build step *immediately* at build time, use `-` in the `waitFor` field.\n\nThe order of the build steps in the `steps` field relates to the order in which\nthe steps are executed. Steps will run serially or concurrently based on the\ndependencies defined in their `waitFor` fields.\n\nA step is dependent on every `id` in its `waitFor` and will not launch until\neach dependency has completed successfully.\n| **Note:** Steps must be defined with the `id` field prior to being used as `waitFor` dependencies.\n\nSteps without the optional `waitFor` field (or with an empty `waitFor`) will\nwait for *all prior steps to complete successfully* before executing. Therefore,\nif no step contains an `id` in its `waitFor` field, then all steps will *execute\nserially in the order they are defined*.\n\nSteps can depend on the start of the build by having `waitFor` contain only\n`-`. By declaring that a step depends only on `-`, the step *runs immediately\nwhen the build starts*. The first step defined depends implicitly on start.\n\nThe following snippet shows a build config with two steps that runs serially: \n\n### YAML\n\n steps:\n - name: foo\n - name: bar\n\n### JSON\n\n {\n \"steps\": [{\n \"name\": \"foo\"\n },\n {\n \"name\": \"bar\"\n }\n ]\n }\n\nThe following snippet shows two concurrent steps that both depend on start; the\nthird step waits for the first two to complete successfully before\nlaunching. This concurrent build runs steps `A` and `B` at the start of the\nbuild. The third step will wait implicitly until both previous steps are\nfinished before starting. This example could be simplified by omitting the `id`\nfields, which are not referenced in a subsequent `waitFor`. \n\n### YAML\n\n steps:\n - name: foo\n id: A\n - name: bar\n id: B\n waitFor: ['-']\n - name: baz\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"foo\",\n \"id\": \"A\"\n },\n {\n \"name\": \"bar\",\n \"id\": \"B\",\n \"waitFor\": [\"-\"]\n },\n {\n \"name\": \"baz\"\n }\n ]\n }\n\nThe following snippet shows concurrent steps that depend on a previous\nstep. Step `A` runs immediately when the build starts. Steps `B` and `C` run\nconcurrently after `A` has completed successfully. Note that the `id` and\n`waitFor` fields in step `B`, and the `id` field in step `C`, could be omitted\nwithout changing the order of execution. \n\n### YAML\n\n steps:\n - name: foo\n id: A\n - name: bar\n id: B\n waitFor:\n - A\n - name: baz\n id: C\n waitFor:\n - A\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"foo\",\n \"id\": \"A\"\n },\n {\n \"name\": \"bar\",\n \"id\": \"B\",\n \"waitFor\": [\n \"A\"\n ]\n },\n {\n \"name\": \"baz\",\n \"id\": \"C\",\n \"waitFor\": [\n \"A\"\n ]\n }\n ]\n }\n\nExamples\n--------\n\nThe example below calls the `gsutil` and `wget` steps concurrently.\nAfter these steps have completed, the `ubuntu` step is called. \n\n### YAML\n\n steps:\n # Download the binary and the data in parallel.\n - name: 'gcr.io/cloud-builders/wget'\n args: ['https://example.com/binary']\n - name: 'gcr.io/cloud-builders/gsutil'\n args: ['cp', 'gs://$PROJECT_ID-data/rawdata.tgz', '.']\n waitFor: ['-'] # The '-' indicates that this step begins immediately.\n\n # Run the binary on the data, once both are downloaded.\n - name: 'ubuntu'\n args: ['./binary', 'rawdata.tgz']\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"gcr.io/cloud-builders/wget\",\n \"args\": [\n \"https://example.com/binary\"\n ]\n },\n {\n \"name\": \"gcr.io/cloud-builders/gsutil\",\n \"args\": [\n \"cp\",\n \"gs://$PROJECT_ID-data/rawdata.tgz\",\n \".\"\n ],\n \"waitFor\": [\n \"-\"\n ]\n },\n {\n \"name\": \"ubuntu\",\n \"args\": [\n \"./binary\",\n \"rawdata.tgz\"\n ]\n }\n ]\n }\n\nThe example below uses the `id` field to identify certain build steps. The values\nfrom `id` are used in `waitFor` to define build step order:\n\n- First, `fetch-resources` step uses `gsutil` to copy the local resources from Cloud Storage. Concurrently, `go` generates, tests, and installs the source code.\n- Then, the `docker` build step builds the image after all other steps are\n complete.\n\n### YAML\n\n steps:\n - name: 'gcr.io/cloud-builders/go'\n args: ['generate']\n - name: 'gcr.io/cloud-builders/go'\n args: ['test', './...']\n - name: 'gcr.io/cloud-builders/go'\n args: ['install', 'mytarget']\n id: 'go-install'\n\n - name: 'gcr.io/cloud-builders/gsutil'\n args: ['cp', '-r', './somefiles', 'gs://my-resource-bucket/somefiles']\n waitFor: ['-'] # The '-' indicates that this step begins immediately.\n id: 'fetch-resources'\n\n - name: 'gcr.io/cloud-builders/docker'\n args: ['build', '-t', 'gcr.io/$PROJECT_ID/mytarget', '.']\n waitFor: ['go-install', 'fetch-resources']\n\n images: ['gcr.io/$PROJECT_ID/mytarget']\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"gcr.io/cloud-builders/go\",\n \"args\": [\n \"generate\"\n ]\n },\n {\n \"name\": \"gcr.io/cloud-builders/go\",\n \"args\": [\n \"test\",\n \"./...\"\n ]\n },\n {\n \"name\": \"gcr.io/cloud-builders/go\",\n \"args\": [\n \"install\",\n \"mytarget\"\n ],\n \"id\": \"go-install\"\n },\n {\n \"name\": \"gcr.io/cloud-builders/gsutil\",\n \"args\": [\n \"cp\",\n \"-r\",\n \"./somefiles\",\n \"gs://my-resource-bucket/somefiles\"\n ],\n \"waitFor\": [\n \"-\"\n ],\n \"id\": \"fetch-resources\"\n },\n {\n \"name\": \"gcr.io/cloud-builders/docker\",\n \"args\": [\n \"build\",\n \"-t\",\n \"gcr.io/$PROJECT_ID/mytarget\",\n \".\"\n ],\n \"waitFor\": [\n \"go-install\",\n \"fetch-resources\"\n ]\n }\n ],\n \"images\": [\n \"gcr.io/$PROJECT_ID/mytarget\"\n ]\n }\n\nWhat's next\n-----------\n\n- Configure Cloud Build to [build, test, and deploy\n artifacts](/build/docs/configuring-builds/build-test-deploy-artifacts).\n- Learn how to run builds [manually](/build/docs/running-builds/start-build-manually) and using [triggers](/build/docs/running-builds/automate-builds)."]]