Questa pagina spiega come configurare Cloud Build per l'esecuzione di script bash all'interno di un passaggio di build. Se non hai mai utilizzato Cloud Build, leggi prima le guide rapide e la panoramica della configurazione di build.
Puoi eseguire script bash all'interno di un passaggio di build per configurare una serie di flussi di lavoro, tra cui:
- Esecuzione di più comandi in un solo passaggio di build.
- Lettura dal file system.
- Basa una logica come nuovi tentativi o condizionali.
- Output nel log, ad esempio con l'esecuzione di
echo $VARNAME
.
Utilizzo del campo script
Cloud Build fornisce un campo script
che puoi utilizzare per specificare gli script shell da eseguire in un passaggio di build. Il campo script
accetta un singolo valore stringa.
Puoi anteporre al valore della stringa shebang per specificare la shell per interpretare lo script. Ad esempio, aggiungi #!/usr/bin/env bash
per specificare la shell Bash. Se non aggiungi il prefisso Shebang alla stringa dello script, Cloud Build utilizza #!/bin/sh
, che è la shell sh di base, non la shell di Bash.
Se specifichi script
in un passaggio di build, non puoi specificare args
o entrypoint
nello stesso passaggio.
Lo snippet seguente illustra il campo 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"
}
]
}
Utilizzare le sostituzioni con il campo script
Gli script non supportano direttamente le sostituzioni, ma supportano le variabili di ambiente. Puoi mappare le sostituzioni alle variabili di ambiente, in modo automatico e contemporaneamente, oppure manualmente definendo manualmente ogni variabile di ambiente.
Sostituzioni automatiche della mappa
A livello di build. Per mappare automaticamente tutte le sostituzioni alle variabili di ambiente, che saranno disponibili nell'intera build, imposta
automapSubstitutions
sutrue
come opzione a livello di build. Ad esempio, il seguente file di configurazione della build mostra la sostituzione definita dall'utente$_USER
e la sostituzione predefinita$PROJECT_ID
mappata alle variabili di ambiente: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" } }
A livello di passaggio. Per mappare automaticamente tutte le sostituzioni e renderle disponibili come variabili di ambiente in un singolo passaggio, imposta il campo
automapSubstitutions
sutrue
in quel passaggio. Nell'esempio seguente, solo il secondo passaggio mostrerà correttamente le sostituzioni, perché è l'unico in cui è abilitata la mappatura delle sostituzioni automatiche: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" }
Inoltre, puoi rendere disponibili le sostituzioni come variabili di ambiente nell'intera build, quindi ignorarle in un solo passaggio. Imposta
automapSubstitutions
sutrue
a livello di build, quindi imposta lo stesso campo sufalse
nel passaggio in cui vuoi ignorare le sostituzioni. Nel seguente esempio, anche se le sostituzioni della mappatura sono abilitate a livello di build, l'ID progetto non verrà stampato nel secondo passaggio perchéautomapSubstitutions
è impostato sufalse
in questo passaggio: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" }
Sostituzioni della mappa manualmente
Puoi mappare manualmente le sostituzioni alle variabili di ambiente. Ogni variabile di ambiente viene definita a livello di passaggio utilizzando il campo env
e l'ambito delle variabili è limitato al passaggio in cui sono definite. Questo campo contiene un elenco di chiavi e valori.
L'esempio seguente mostra come mappare la sostituzione $PROJECT_ID
alla
variabile di ambiente BAR
:
YAML
steps:
- name: 'ubuntu'
env:
- 'BAR=$PROJECT_ID'
script: 'echo $BAR'
JSON
{
"steps": [
{
"name": "ubuntu",
"env": [
"BAR=$PROJECT_ID"
],
"script": "echo $BAR"
}
]
}
Esecuzione di script bash su disco
Se hai salvato lo script bash in un file, archivialo insieme all'origine della build e fai riferimento al file di script all'interno del file di configurazione della build:
YAML
steps:
- name: 'bash'
args: ['./myscript.bash']
JSON
{
"steps": [
{
"name": "bash",
"args": [
"./myscript.bash"
]
}
]
}
Per utilizzare uno script bash nel file se bash non è il punto di ingresso predefinito dell'immagine che stai utilizzando, aggiungi un campo entrypoint
che rimanda a bash:
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"
]
}
]
}
Esecuzione di script bash incorporati (legacy)
Per eseguire i comandi bash utilizzando l'immagine bash
, specifica bash
come name
del passaggio di build e il comando nel campo args:
YAML
steps:
- name: 'bash'
args: ['echo', 'I am running a bash command']
JSON
{
"steps": [
{
"name": "bash",
"args": [
"echo",
"I am running a bash command"
]
}
]
}
Se l'immagine che stai utilizzando è già inclusa nel pacchetto bash
, ma se bash
non è il punto di ingresso predefinito, aggiungi un campo entrypoint
che rimanda a bash
. Nell'esempio riportato di seguito, il punto di ingresso bash
viene utilizzato per eseguire i comandi gcloud
che eseguono query su Cloud Build per conoscere lo stato della build, elencando le build con uno stato Non riuscito.
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"
]
}
]
}
Il flag -c
nel codice riportato sopra viene utilizzato per eseguire comandi su più righe. Qualsiasi stringa passata dopo -c
viene trattata come un comando. Per ulteriori informazioni sull'esecuzione dei comandi bash con -c
, consulta la documentazione di Bash.
Passaggi successivi
- Scopri come avviare una build manualmente.
- Scopri come automatizzare le build utilizzando i trigger.
- Scopri come configurare l'ordine dei passi di build.
- Scopri come utilizzare i builder personalizzati e forniti dalla community.