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 criação. O campo script
usa um único valor de string.
É possível prefixar o valor da string com um shebang
para especificar o shell a fim de interpretar o script. Por exemplo, adicione #!/usr/bin/env bash
para especificar o shell Bash. Se você não prefixar a string do script com um Shebang, o Cloud Build vai usar #!/bin/sh
, que é o shell sh básico, não o shell Bash.
Se você especificar script
em uma etapa de criação, 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 dão suporte direto a substituições, mas são compatíveis com variáveis de ambiente. É possível mapear substituições para variáveis de ambiente de forma automática de uma só vez ou manualmente, definindo cada variável de ambiente por conta própria.
Substituições de mapas automaticamente
No nível de 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 da versão. 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
mapeada 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 a seguir, somente a segunda etapa mostrará as substituições corretamente, porque é a única com o mapeamento automático de substituições 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 em todo o build e ignorá-las em uma etapa. Defina
automapSubstitutions
comotrue
no nível da criação e, em seguida, defina o mesmo campo comofalse
na etapa em que você quer ignorar as substituições. No exemplo a seguir, mesmo que as substituições de mapeamento estejam ativadas no nível da versão, 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" }
Substituições de mapas 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 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 inline (legado)
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 vier pré-empacotada com bash
, mas se bash
não for o ponto de entrada padrão, adicione um campo entrypoint
apontando para bash
. No exemplo
abaixo, o ponto de entrada bash
é usado para executar comandos gcloud
que consultam
o status da versão no Cloud Build, listando as versões com 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.