Auf dieser Seite wird erläutert, wie Sie Cloud Build so konfigurieren, dass Bash-Skripts innerhalb eines Build-Schritts ausgeführt werden. Wenn Sie Cloud Build noch nicht kennen, lesen Sie zuerst die Kurzanleitungen sowie Build-Konfiguration – Überblick.
Sie können innerhalb eines Build-Schritts Bash-Skripts ausführen, um eine Reihe von Workflows zu konfigurieren, darunter:
- Mehrere Befehle in einem Build-Schritt ausführen
- Aus dem Dateisystem lesen.
- Logik wie Wiederholungsversuche oder Bedingungen einbauen.
- Ausgabe in das Log, z. B. Ausführung von
echo $VARNAME
.
Feld script
verwenden
Cloud Build bietet ein script
-Feld, mit dem Sie Shell-Skripts angeben können, die in einem Build-Schritt ausgeführt werden sollen. Das Feld script
verwendet einen einzelnen Stringwert.
Sie können dem Stringwert shebang voranstellen, um die Shell anzugeben, die das Skript interpretiert. Fügen Sie beispielsweise #!/usr/bin/env bash
hinzu, um die Bash-Shell anzugeben. Wenn Sie dem Skriptstring kein Shebang voranstellen, verwendet Cloud Build #!/bin/sh
. Dies ist die grundlegende sh-Shell, nicht die Bash-Shell.
Wenn Sie script
in einem Build-Schritt angeben, können Sie im selben Schritt weder args
noch entrypoint
angeben.
Das folgende Snippet veranschaulicht das Feld script
:
YAML
steps:
- name: 'bash'
script: |
#!/usr/bin/env bash
echo "Hello World"
- name: 'ubuntu'
script: echo hello
- name: 'python'
script: |
#!/usr/bin/env python
print('hello from python')
JSON
{
"steps": [
{
"name": "bash",
"script": "#!/usr/bin/env bash echo 'Hello World'"
},
{
"name": "ubuntu",
"script": "echo hello"
},
{
"name": "python",
"script": "#!/usr/bin/env python\nprint('hello from python')\n"
}
]
}
Substitutionen mit dem Feld script
verwenden
Skripts unterstützen Substitutionen nicht direkt, aber Umgebungsvariablen. Sie können Substitutionen Umgebungsvariablen entweder automatisch auf einmal oder manuell festlegen, indem Sie jede Umgebungsvariable selbst definieren.
Automatische Ersetzung von Karten
Auf Build-Ebene: Wenn alle Substitutionen automatisch Umgebungsvariablen zugeordnet werden sollen, die im gesamten Build verfügbar sind, legen Sie auf Build-Ebene für
automapSubstitutions
die Optiontrue
fest. Die folgende Build-Konfigurationsdatei zeigt beispielsweise die benutzerdefinierte Substitution$_USER
und die Standardersetzung$PROJECT_ID
, die Umgebungsvariablen zugeordnet sind:YAML
steps: - name: 'ubuntu' script: | #!/usr/bin/env bash echo "Hello $_USER" - name: 'ubuntu' script: | #!/usr/bin/env bash echo "Your project ID is $PROJECT_ID" options: automapSubstitutions: true substitutions: _USER: "Google Cloud"
JSON
{ "steps": [ { "name": "ubuntu", "script": "#!/usr/bin/env bash echo 'Hello $_USER'" }, { "name": "ubuntu", "script": "#!/usr/bin/env bash echo 'Your project ID is $PROJECT_ID'" } ], "options": { "automap_substitutions": true }, "substitutions": { "_USER": "Google Cloud" } }
Auf Schrittebene: Wenn alle Substitutionen automatisch zugeordnet und als Umgebungsvariablen in einem Schritt verfügbar gemacht werden sollen, setzen Sie das Feld
automapSubstitutions
in diesem Schritt auftrue
. Im folgenden Beispiel werden nur im zweiten Schritt die Substitutionen korrekt angezeigt, da die automatische Substitutionszuordnung nur hier aktiviert ist:YAML
steps: - name: 'ubuntu' script: | #!/usr/bin/env bash echo "Hello $_USER" - name: 'ubuntu' script: | #!/usr/bin/env bash echo "Your project ID is $PROJECT_ID" automapSubstitutions: true substitutions: _USER: "Google Cloud"
JSON
{ "steps": [ { "name": "ubuntu", "script": "#!/usr/bin/env bash echo 'Hello $_USER'" }, { "name": "ubuntu", "script": "#!/usr/bin/env bash echo 'Your project ID is $PROJECT_ID'", "automap_substitutions": true } ], }, "substitutions": { "_USER": "Google Cloud" }
Außerdem können Sie die Substitutionen als Umgebungsvariablen im gesamten Build verfügbar machen und dann in einem Schritt ignorieren. Setzen Sie
automapSubstitutions
auftrue
auf Build-Ebene und setzen Sie dann dasselbe Feld in dem Schritt, in dem Sie die Substitutionen ignorieren möchten, auffalse
. Im folgenden Beispiel ist die Projekt-ID im zweiten Schritt nicht ausgegeben, obwohl die Zuordnung von Substitutionen auf Build-Ebene aktiviert ist, daautomapSubstitutions
in diesem Schritt auffalse
gesetzt ist:YAML
steps: - name: 'ubuntu' script: | #!/usr/bin/env bash echo "Hello $_USER" - name: 'ubuntu' script: | #!/usr/bin/env bash echo "Your project ID is $PROJECT_ID" automapSubstitutions: false options: automapSubstitutions: true substitutions: _USER: "Google Cloud"
JSON
{ "steps": [ { "name": "ubuntu", "script": "#!/usr/bin/env bash echo 'Hello $_USER'" }, { "name": "ubuntu", "script": "#!/usr/bin/env bash echo 'Your project ID is $PROJECT_ID'", "automap_substitutions": false } ], "options": { "automap_substitutions": true }, }, "substitutions": { "_USER": "Google Cloud" }
Manuelle Kartenersetzungen
Sie können die Substitutionen Umgebungsvariablen manuell zuordnen. Jede Umgebungsvariable wird auf Schrittebene mithilfe des Felds env
definiert. Der Bereich der Variablen ist auf den Schritt beschränkt, in dem sie definiert werden. Dieses Feld enthält eine Liste mit Schlüsseln und Werten.
Das folgende Beispiel zeigt, wie die Substitution $PROJECT_ID
der Umgebungsvariablen BAR
zugeordnet wird:
YAML
steps:
- name: 'ubuntu'
env:
- 'BAR=$PROJECT_ID'
script: 'echo $BAR'
JSON
{
"steps": [
{
"name": "ubuntu",
"env": [
"BAR=$PROJECT_ID"
],
"script": "echo $BAR"
}
]
}
Bash-Skripts auf dem Laufwerk ausführen
Wenn Sie Ihr Bash-Skript in einer Datei gespeichert haben, speichern Sie die Datei zusammen mit Ihrer Build-Quelle und verweisen Sie in der Build-Konfigurationsdatei auf die Skriptdatei:
YAML
steps:
- name: 'bash'
args: ['./myscript.bash']
JSON
{
"steps": [
{
"name": "bash",
"args": [
"./myscript.bash"
]
}
]
}
Fügen Sie zur Verwendung eines Bash-Skripts in der Datei, wenn Bash nicht der Standardeinstiegspunkt des verwendeten Images ist, das Feld entrypoint
hinzu, das auf Bash verweist:
YAML
steps:
- name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args: ['tools/myScript.sh','--foo']
JSON
{
"steps": [
{
"name": "gcr.io/cloud-builders/gcloud",
"entrypoint": "bash",
"args": [
"tools/myScript.sh",
"--foo"
]
}
]
}
Inline-Bash-Skripts ausführen (Legacy)
Geben Sie zum Ausführen von Bash-Befehlen mit dem Image bash
bash
als name
des Build-Schritts und den Befehl im Feld "args" an:
YAML
steps:
- name: 'bash'
args: ['echo', 'I am running a bash command']
JSON
{
"steps": [
{
"name": "bash",
"args": [
"echo",
"I am running a bash command"
]
}
]
}
Wenn das von Ihnen verwendete Image bereits bash
enthält, bash
aber nicht der Standardeinstiegspunkt ist, fügen Sie ein entrypoint
-Feld hinzu, das auf bash
verweist. Im folgenden Beispiel wird der Einstiegspunkt bash
verwendet, um gcloud
-Befehle auszuführen, die den Build-Status von Cloud Build abfragen und Builds mit dem Status „Fehlgeschlagen“ auflisten.
YAML
steps:
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
entrypoint: 'bash'
args:
- '-eEuo'
- 'pipefail'
- '-c'
- |-
gcloud builds list > builds.txt
while read line; do
if grep -q "FAILURE" <<< "$line"; then
echo "$line"
fi
done < builds.txt
JSON
{
"steps": [
{
"name": "gcr.io/google.com/cloudsdktool/cloud-sdk",
"entrypoint": "bash",
"args": [
"-eEuo",
"pipefail",
"-c",
"gcloud builds list > builds.txt\nwhile read line; do\n if grep -q \"FAILURE\" <<< \"$line\"; then\n echo \"$line\"\n fi\ndone < builds.txt"
]
}
]
}
Das Flag -c
im obigen Code wird zum Ausführen mehrzeiliger Befehle verwendet. Jeder String, den Sie nach -c
übergeben, wird als Befehl behandelt. Weitere Informationen zum Ausführen von Bash-Befehlen mit -c
finden Sie in der Bash-Dokumentation.
Nächste Schritte
- Build manuell starten
- Builds mit Build-Triggern automatisieren
- Reihenfolge der Build-Schritte konfigurieren
- Hier erfahren Sie, wie Sie Community-Builder und benutzerdefinierte Builder verwenden.