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.
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"
}
]
}
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.
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"
]
}
]
}
Beispiele
Im folgenden Beispiel werden die Schritte gcloud storage 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/gcloud'
args: ['storage', '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/gcloud",
"args": [
"storage",
"cp",
"gs://$PROJECT_ID-data/rawdata.tgz",
"."
],
"waitFor": [
"-"
]
},
{
"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-resourcesverwendet zuerstgcloud storage, um die lokalen Ressourcen aus Cloud Storage zu kopieren. Gleichzeitig wird mitgoder Quellcode generiert, getestet und installiert. Nach Abschluss aller anderen Schritte wird mithilfe des Build-Schritts
dockerdas 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/gcloud'
args: ['storage', '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/gcloud",
"args": [
"storage",
"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"
]
}
Weitere Informationen
- Artefakte mit Cloud Build erstellen, testen und bereitstellen
- Builds manuell ausführen und Builds mit Build-Triggern automatisieren