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 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']
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"
]
}
]
}
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 zuerstgsutil
, um die lokalen Ressourcen aus Cloud Storage zu kopieren. Gleichzeitig wird mitgo
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']
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"
]
}
Weitere Informationen
- Artefakte mit Cloud Build erstellen, testen und bereitstellen
- Builds manuell ausführen und Builds mit Build-Triggern automatisieren