Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Sie können die Reihenfolge festlegen, in der Ihre Build-Schritte ausgeführt werden sollen. Build-Schritte werden standardmäßig nacheinander ausgeführt, Sie können sie jedoch so konfigurieren, dass sie gleichzeitig ausgeführt werden.
Auf dieser Seite wird erläutert, wie die Reihenfolge der Build-Schritte konfiguriert wird.
Abfolge und Abhängigkeiten von Build-Schritten
Geben Sie in einem Build-Schritt mit dem Feld waitFor an, welche Schritte vor dem Ausführen des Build-Schritts ausgeführt werden müssen. Wenn Sie für waitFor keine Werte angeben, wartet der Build-Schritt erst auf die erfolgreiche Ausführung aller vorherigen Build-Schritte in der Build-Anfrage.
Wenn Sie einen Build-Schritt sofort bei der Build-Erstellung ausführen möchten, geben Sie in das Feld waitFor ein Minuszeichen (-) ein.
Die Reihenfolge der im Feld steps aufgelisteten Build-Schritte entspricht der Reihenfolge, in der die Schritte ausgeführt werden. Ob die Schritte nacheinander oder gleichzeitig ausgeführt werden, richtet sich nach den im Feld waitFor festgelegten Abhängigkeiten.
Ein Schritt ist von jeder id in seinem waitFor abhängig und startet erst dann, wenn alle Abhängigkeiten erfolgreich abgeschlossen wurden.
Schritte ohne das optionale Feld waitFor werden erst nach erfolgreichem Abschluss aller vorangegangenen Schritte ausgeführt. Gleiches gilt, wenn das Feld waitFor leer ist. Wenn also kein Schritt eine id in seinem Feld waitFor enthält, werden alle Schritte in der Reihenfolge ausgeführt, in der sie definiert wurden.
Wenn für Schritte im Feld waitFor nur - angegeben ist, können sie vom Build-Start abhängig sein. Wenn Sie festlegen, dass ein Schritt nur von - abhängig ist, wird der Schritt sofort beim Build-Start ausgeführt. Der erste festgelegte Schritt hängt implizit vom Start ab.
Das folgende Snippet zeigt eine Build-Konfiguration mit zwei Schritten, die nacheinander ausgeführt werden:
YAML
steps:-name:foo-name:bar
JSON
{"steps":[{"name":"foo"},{"name":"bar"}]}
Das folgende Snippet zeigt zwei gleichzeitig auszuführende Schritte, die beide vom Start abhängig sind. Der dritte Schritt wird erst nach erfolgreichem Abschluss der beiden vorangegangenen Schritte ausgeführt. Dieser Build führt bei seinem Start gleichzeitig Schritt A und Schritt B aus. Der dritte Schritt wartet implizit, bis die beiden vorherigen Schritte abgeschlossen sind, bevor er startet. Dieses Beispiel könnte durch Weglassen der nicht in einem nachfolgenden Feld waitFor referenzierten id-Felder vereinfacht werden.
Das folgende Snippet zeigt gleichzeitig ausgeführte Schritte, die von einem vorherigen Schritt abhängen. Schritt A wird sofort ausgeführt, wenn der Build gestartet wird. Die Schritte B und C werden gleichzeitig ausgeführt, nachdem A erfolgreich abgeschlossen wurde. Die Felder id und waitFor in Schritt B und das Feld id in Schritt C könnten weggelassen werden, ohne dass sich die Reihenfolge der Ausführung ändert.
Im folgenden Beispiel werden die Schritte gsutil und wget gleichzeitig aufgerufen.
Nach Abschluss dieser Schritte wird der Schritt ubuntu aufgerufen.
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']
Im folgenden Beispiel wird das Feld id dazu verwendet, bestimmte Build-Schritte zu ermitteln. Die Werte aus id sind in waitFor angegeben, damit die Reihenfolge der Build-Schritte festgelegt werden kann:
Der Schritt fetch-resources verwendet zuerst gsutil, um die lokalen Ressourcen aus Cloud Storage zu kopieren. Gleichzeitig wird mit go der Quellcode generiert, getestet und installiert.
Nach Abschluss aller anderen Schritte wird mithilfe des Build-Schritts docker das Image erstellt.
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']
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (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)."]]