Running bash scripts
You can run bash scripts within a build step to configure a number of workflows including:
- Running multiple commands in one build step.
- Reading from the filesystem.
- Building in logic such as retries or conditionals.
- Outputting to the log, for example, running
echo $VARNAME
.
Using the script
field
Cloud Build provides a script
field that you can use to specify shell scripts to execute in a build step. The script
field takes a single string value.
You can prefix the string value with a shebang to specify the shell to interpret the script. For example, add #!/usr/bin/env bash
to specify the Bash shell. If you don't prefix the script string with a shebang, Cloud Build uses #!/bin/sh
which is the basic sh shell, not Bash shell.
If you specify script
in a build step, you cannot specify args
or entrypoint
in the same step.
The following snippet demonstrates the script
field:
Using substitutions with the script
field
Scripts don't directly support substitutions, but they support environment variables. You can map substitutions to environment variables, either automatically all at once, or manually by defining every environment variable yourself.
Map substitutions automatically
At the build level. To automatically map all the substitutions to environment variables, which will be available throughout the entire build, set
automapSubstitutions
totrue
as an option at the build level. For example, the following build config file shows the user-defined substitution$_USER
and the default substitution$PROJECT_ID
mapped to environment variables:At the step level. To automatically map all the substitutions and make them available as environment variables in a single step, set the
automapSubstitutions
field totrue
in that step. In the following example, only the second step will show the substitutions correctly, because it's the only one with automatic substitutions mapping enabled:Additionally, you can make the substitutions available as environment variables in the entire build, then ignore them in one step. Set
automapSubstitutions
totrue
at the build level, then set the same field tofalse
in the step where you want to ignore the substitutions. In the following example, even though mapping substitutions is enabled at the build level, the project ID will not be printed in the second step, becauseautomapSubstitutions
is set tofalse
in that step:
Map substitutions manually
You can manually map the substitutions to environment variables. Every environment variable is defined at the step level using the env
field, and the scope of the variables is restricted to the step where they are defined. This field takes a list of keys and values.
The following example shows how to map the substitution $PROJECT_ID
to the environment variable BAR
:
Running bash scripts on disk
If you have your bash script saved in a file, store the file along with your build source, and reference the script file within your build config file:
To use a bash script on file if bash is not the default entrypoint of the image you're using, add an entrypoint
field pointing to bash:
Running inline bash scripts (legacy)
To run bash commands using the bash
image, specify bash
as the name
of the build step, and the command in the args field:
If the image you're using comes prepackaged with bash
but if bash
is not the default entrypoint, add an entrypoint
field pointing to bash
. In the example below, the bash
entrypoint is used to run gcloud
commands that query Cloud Build for build status, listing builds with a failed status.
The -c
flag in the code above is used to execute multi-line commands. Any string you pass after -c
is treated as a command. For more information on running bash commands with -c
, see the bash documentation.
Comments
Post a Comment