Questa pagina spiega come configurare Cloud Build per eseguire script bash all'interno di un passaggio di creazione. Se non hai mai utilizzato Cloud Build, leggi prima le guide rapide e la panoramica della configurazione di compilazione.
Puoi eseguire script bash all'interno di un passaggio di creazione per configurare una serie di workflow, tra cui:
- Esecuzione di più comandi in un unico passaggio di build.
- Lettura dal file system.
- Incorporare logica come i tentativi o le condizioni.
- Output nel log, ad esempio 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 aggiungere un shebang come prefisso al valore della stringa
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, ovvero la shell sh di base, non la shell Bash.
Se specifichi script in un passaggio di build, non puoi specificare args o entrypoint
nello stesso passaggio.
Il seguente snippet mostra 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 tutte in una volta o manualmente definendo ogni variabile di ambiente personalmente.
Mappare automaticamente le sostituzioni
A livello di build. Per mappare automaticamente tutte le sostituzioni alle variabili di ambiente, che saranno disponibili durante l'intera build, imposta
automapSubstitutionssutruecome opzione a livello di build. Ad esempio, il seguente file di configurazione della build mostra la sostituzione$_USERdefinita dall'utente e la sostituzione$PROJECT_IDpredefinita mappate 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 unico passaggio, imposta il campo
automapSubstitutionssutruein questo passaggio. Nell'esempio seguente, solo il secondo passaggio mostrerà le sostituzioni correttamente, perché è l'unico con la mappatura delle sostituzioni automatiche attivata: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 unico passaggio. Imposta
automapSubstitutionssutruea livello di build, quindi imposta lo stesso campo sufalsenel passaggio in cui vuoi ignorare le sostituzioni. Nell'esempio seguente, anche se le sostituzioni del mapping sono abilitate a livello di build, l'ID progetto non verrà stampato nel secondo passaggio, perchéautomapSubstitutionsè impostato sufalsein 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" }
Mappare manualmente le sostituzioni
Puoi mappare manualmente le sostituzioni alle variabili di ambiente. Ogni
variabile di ambiente è definita a livello di passaggio utilizzando il campo
env e l'ambito delle variabili è limitato al passaggio
in cui sono definite. Questo campo accetta 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 sul 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 sul file se bash non è il punto di ingresso predefinito dell'immagine che stai utilizzando, aggiungi un campo entrypoint che rimandi 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
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 utilizzi è preinstallata con bash, ma se bash non è il
punto di ingresso predefinito, aggiungi un campo entrypoint che rimandi a bash. Nell'esempio
di seguito, il punto di ingresso bash viene utilizzato per eseguire i comandi gcloud che eseguono query
su Cloud Build per lo stato della build, elencando le build con 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 precedente viene utilizzato per eseguire comandi su più righe. Qualsiasi stringa
che passi dopo -c viene trattata come un comando. Per saperne di più 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 passaggi di build.
- Scopri come utilizzare i builder personalizzati e forniti dalla community.