Nesta página, explicamos como configurar o Cloud Build para executar scripts bash em uma etapa de versão. Se você não estiver familiarizado com o Cloud Build, leia as guias de início rápido e a visão geral da configuração do Build primeiro.
É possível executar scripts bash em uma etapa de versão para configurar vários fluxos de trabalho, incluindo:
- Como executar vários comandos em uma etapa de versão.
- Leitura do sistema de arquivos.
- Criação em lógica, como novas tentativas ou condicionais.
- Saída para o registro, por exemplo, executando
echo $VARNAME
.
Como usar o campo script
O Cloud Build fornece um campo script
que pode ser usado para especificar
scripts de shell a serem executados em uma etapa de build. O campo script
recebe um único valor de
string.
É possível prefixar o valor da string com um shebang
para especificar o shell que vai interpretar o script. Por exemplo, adicione #!/usr/bin/env bash
para especificar o shell Bash. Se você não colocar um prefixo shebang na string do script, o Cloud Build vai usar #!/bin/sh
, que é o shell sh básico, e não o Bash.
Se você especificar script
em uma etapa de build, não será possível especificar args
ou entrypoint
na mesma etapa.
O snippet a seguir demonstra o 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"
}
]
}
Como usar substituições com o campo script
Os scripts não têm suporte direto a substituições, mas têm suporte a variáveis de ambiente. É possível mapear substituições para variáveis de ambiente, automaticamente de uma só vez ou manualmente definindo cada variável de ambiente.
Mapear substituições automaticamente
No nível do build. Para mapear automaticamente todas as substituições para variáveis de ambiente, que estarão disponíveis em todo o build, defina
automapSubstitutions
comotrue
como uma opção no nível do build. Por exemplo, o arquivo de configuração de build a seguir mostra a substituição definida pelo usuário$_USER
e a substituição padrão$PROJECT_ID
mapeadas para variáveis de 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" } }
No nível da etapa. Para mapear automaticamente todas as substituições e disponibilizá-las como variáveis de ambiente em uma única etapa, defina o campo
automapSubstitutions
comotrue
nessa etapa. No exemplo abaixo, apenas a segunda etapa mostra as substituições corretamente, porque é a única com o mapeamento de substituições automáticas ativado: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" }
Além disso, é possível disponibilizar as substituições como variáveis de ambiente no build inteiro e ignorá-las em uma etapa. Defina
automapSubstitutions
comotrue
no nível do build e, em seguida, defina o mesmo campo comofalse
na etapa em que você quer ignorar as substituições. No exemplo abaixo, mesmo que as substituições de mapeamento estejam ativadas no nível de build, o ID do projeto não será impresso na segunda etapa porqueautomapSubstitutions
está definido comofalse
nessa etapa: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" }
Mapear substituições manualmente
É possível mapear manualmente as substituições para variáveis de ambiente. Cada
variável de ambiente é definida no nível da etapa usando o campo
env
, e o escopo das variáveis é restrito à etapa
em que elas são definidas. Esse campo usa uma lista de chaves e valores.
O exemplo a seguir mostra como mapear a substituição $PROJECT_ID
para a
variável de ambiente BAR
:
YAML
steps:
- name: 'ubuntu'
env:
- 'BAR=$PROJECT_ID'
script: 'echo $BAR'
JSON
{
"steps": [
{
"name": "ubuntu",
"env": [
"BAR=$PROJECT_ID"
],
"script": "echo $BAR"
}
]
}
Como executar scripts bash no disco
Se você tiver o script bash salvo em um arquivo, armazene-o junto com a origem da versão e faça referência ao arquivo de script no arquivo de configuração da versão:
YAML
steps:
- name: 'bash'
args: ['./myscript.bash']
JSON
{
"steps": [
{
"name": "bash",
"args": [
"./myscript.bash"
]
}
]
}
Para usar um script bash se o bash não for o entrypoint padrão da imagem
que você está usando, adicione um campo entrypoint
que indique o 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"
]
}
]
}
Como executar scripts bash in-line
Para executar comandos bash usando a imagem bash
, especifique bash
como o name
da etapa de versão e o comando no 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 a imagem que você está usando for fornecida com bash
, mas se bash
não for o
entrypoint padrão, adicione um campo entrypoint
que aponte para bash
. No exemplo
abaixo, o ponto de entrada bash
é usado para executar comandos gcloud
que consultam
o status do build do Cloud Build, listando builds com um status de falha.
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"
]
}
]
}
A sinalização -c
no código acima é usada para executar comandos de várias linhas. Qualquer string
que você passar depois de -c
será tratada como um comando. Para mais informações sobre como executar comandos bash
com -c
, consulte a
documentação do bash.
A seguir
- Saiba como iniciar uma versão manualmente.
- Saiba como automatizar versões usando gatilhos.
- Saiba como configurar a ordem das etapas de versão.
- Saiba como usar builders de contribuições da comunidade e builders personalizados.