Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Puedes especificar el orden en el que se ejecutan los pasos de compilación. De forma predeterminada, los pasos de compilación se ejecutan de manera secuencial, pero puedes configurarlos para que se ejecuten en simultáneo.
En esta página, se explica cómo configurar el orden de los pasos de compilación.
Orden y dependencias de los pasos de compilación
Usa el campo waitFor del paso de compilación para especificar qué pasos se deben ejecutar antes que dicho paso. Si no se proporciona ningún valor en waitFor, el paso de compilación no se ejecutará hasta que todos los pasos de compilación de la solicitud de compilación se completen de manera correcta.
Para ejecutar un paso de compilación de forma inmediata en el tiempo de compilación, usa - en el campo waitFor.
Los pasos de compilación del campo steps siguen el orden en el que se ejecutan. Los pasos se ejecutarán en serie o de forma simultánea según las dependencias definidas en los campos waitFor.
Los pasos dependen del id del campo waitFor, y no se iniciarán hasta que cada dependencia se complete de manera correcta.
Los pasos que no cuenten con el campo opcional waitFor (o cuyo campo waitFor esté vacío) no se ejecutarán hasta que todos los pasos anteriores se completen de manera correcta. Por lo tanto, si ningún paso contiene un id en el campo waitFor, todos los pasos se ejecutarán en serie según el orden en el que se definieron.
Los pasos pueden depender del inicio de la compilación si waitFor solo contiene -. Si declaras que un paso depende solo de -, este se ejecutará de forma inmediata cuando se inicie la compilación. El primer paso definido depende, de forma implícita, del inicio.
En el siguiente fragmento, se muestra una configuración de compilación con dos pasos que se ejecutan de forma consecutiva:
YAML
steps:-name:foo-name:bar
JSON
{"steps":[{"name":"foo"},{"name":"bar"}]}
En el fragmento siguiente, se muestran dos pasos simultáneos que dependen del inicio. El tercer paso espera a que los dos primeros se completen de forma correcta antes de iniciarse. Esta compilación simultánea ejecuta los pasos A y B al comienzo de la compilación. Antes de comenzar, el tercer paso esperará, de forma implícita, hasta que los dos pasos anteriores finalicen. Este ejemplo se podría simplificar si se omiten los campos id, que no aparecen en ningún waitFor posterior.
En el siguiente fragmento, se muestran pasos simultáneos que dependen de un paso anterior. El paso A se ejecuta de forma inmediata cuando comienza la compilación. Los pasos B y C se ejecutan en simultáneo una vez que A se completa de manera correcta. Ten en cuenta que los campos id y waitFor del paso B y el campo id del paso C se podrían omitir sin cambiar el orden de ejecución.
En el siguiente ejemplo, se llama a los pasos gsutil y wget de forma simultánea.
Cuando se completan estos pasos, se llama al paso 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']
En el siguiente ejemplo, se usa el campo id para identificar ciertos pasos de compilación. Los valores de id se usan en waitFor para definir el orden de los pasos de compilación, como se indica a continuación:
Primero, en el paso fetch-resources se usa gsutil para copiar los recursos locales desde Cloud Storage. Al mismo tiempo, go genera, prueba y, luego, instala el código fuente.
Luego, una vez que se completan los otros pasos, el paso de compilación docker compila la imagen.
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 comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)."]]