이 페이지에서는 빌드 단계 내에서 bash 스크립트를 실행하도록 Cloud Build를 구성하는 방법을 설명합니다. Cloud Build를 처음 사용하는 경우 빠른 시작 및 빌드 구성 개요를 먼저 읽어보세요.
빌드 단계 내에서 bash 스크립트를 실행하여 많은 스크립트를 구성할 수 있습니다.
하나의 빌드 단계로 여러 명령어를 실행합니다.
파일 시스템에서 읽기를 수행합니다.
재시도 또는 조건과 같은 논리를 빌드합니다.
echo $VARNAME 실행과 같이 로그로 출력합니다.
script 필드 사용
Cloud Build는 빌드 단계에서 실행할 셸 스크립트를 지정하는 데 사용할 수 있는 script 필드를 제공합니다. script 필드는 단일 문자열 값을 사용합니다.
문자열 값에 shebang 프리픽스를 추가하여 스크립트를 해석하는 셸을 지정할 수 있습니다. 예를 들어 Bash 셸을 지정하려면 #!/usr/bin/env bash를 추가합니다. 스크립트 문자열에 shebang 프리픽스를 붙이지 않으면 Cloud Build는 Bash 셸이 아닌 기본 sh 셸인 #!/bin/sh를 사용합니다.
빌드 단계에서 script를 지정하면 동일한 단계에서 args 또는 entrypoint을 지정할 수 없습니다.
다음 스니펫은 script 필드를 보여줍니다.
YAML
steps:-name:'bash'script:|#!/usr/bin/env bashecho "Hello World"-name:'ubuntu'script:echo hello-name:'python'script:|#!/usr/bin/env pythonprint('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"}]}
script 필드에 대체 항목 사용
스크립트는 대체 항목을 직접 지원하지 않지만 환경 변수를 지원합니다. 모든 환경 변수를 직접 정의하여 대체 항목을 환경 변수에 자동으로 모두 한 번에 또는 수동으로 매핑할 수 있습니다.
대체 항목 자동 매핑
빌드 수준에서. 모든 대체 항목을 전체 빌드에서 사용할 수 있는 환경 변수에 자동으로 매핑하려면 빌드 수준의 옵션으로 automapSubstitutions를 true로 설정합니다. 예를 들어 다음 빌드 구성 파일은 환경 변수에 매핑된 사용자 정의된 대체 항목 $_USER 및 기본 대체 항목 $PROJECT_ID를 보여줍니다.
YAML
steps:-name:'ubuntu'script:|#!/usr/bin/env bashecho "Hello $_USER"-name:'ubuntu'script:|#!/usr/bin/env bashecho "Your project ID is $PROJECT_ID"options:automapSubstitutions:truesubstitutions:_USER:"GoogleCloud"
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"}}
단계 수준에서. 모든 대체 항목을 자동으로 매핑하고 한 번에 환경 변수로 사용할 수 있게 하려면 해당 단계에서 automapSubstitutions 필드를 true로 설정합니다. 다음 예시에서는 자동 대체 항목 매핑이 사용 설정된 유일한 항목이므로 두 번째 단계에서만 대체 항목이 올바르게 표시됩니다.
YAML
steps:-name:'ubuntu'script:|#!/usr/bin/env bashecho "Hello $_USER"-name:'ubuntu'script:|#!/usr/bin/env bashecho "Your project ID is $PROJECT_ID"automapSubstitutions:truesubstitutions:_USER:"GoogleCloud"
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"}
또한 전체 빌드에서 대체 항목을 환경 변수로 사용할 수 있게 설정한 후 한 번에 무시해도 됩니다. 빌드 수준에서 automapSubstitutions를 true로 설정한 후 대체 항목을 무시하려는 단계에서 동일한 필드를 false로 설정합니다. 다음 예시에서는 빌드 수준에서 매핑 대체 항목이 사용 설정되어 있더라도 automapSubstitutions가 해당 단계에서 false로 설정되어 있기 때문에 프로젝트 ID가 두 번째 단계에서 출력되지 않습니다.
YAML
steps:-name:'ubuntu'script:|#!/usr/bin/env bashecho "Hello $_USER"-name:'ubuntu'script:|#!/usr/bin/env bashecho "Your project ID is $PROJECT_ID"automapSubstitutions:falseoptions:automapSubstitutions:truesubstitutions:_USER:"GoogleCloud"
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"}
수동으로 대체 항목 매핑
대체 항목을 환경 변수에 수동으로 매핑할 수 있습니다. 모든 환경 변수는 env 필드를 사용하여 단계 수준에서 정의되며 변수 범위는 변수가 정의된 단계로 제한됩니다. 이 필드에는 키와 값의 목록이 사용됩니다.
다음 예시에서는 대체 항목 $PROJECT_ID을 환경 변수 BAR에 매핑하는 방법을 보여줍니다.
{"steps":[{"name":"bash","args":["echo","I am running a bash command"]}]}
사용 중인 이미지에 bash가 미리 포함되었지만 bash가 기본 진입점이 아니면 bash를 가리키는 entrypoint 필드를 추가합니다. 아래 예시에서 bash 진입점은 Cloud Build에 빌드 상태를 쿼리하고 실패 상태의 빌드를 나열하는 gcloud 명령어를 실행하는 데 사용됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eCloud Build enables the execution of bash scripts within a build step using the \u003ccode\u003escript\u003c/code\u003e field, which can handle multiple commands, filesystem interactions, logic, and logging.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003escript\u003c/code\u003e field accepts a string value prefixed with a shebang (e.g., \u003ccode\u003e#!/usr/bin/env bash\u003c/code\u003e) to specify the desired shell; otherwise, it defaults to \u003ccode\u003e#!/bin/sh\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eSubstitutions can be used in scripts as environment variables by setting \u003ccode\u003eautomapSubstitutions\u003c/code\u003e to \u003ccode\u003etrue\u003c/code\u003e at either the build level or within individual steps, allowing for dynamic values.\u003c/p\u003e\n"],["\u003cp\u003eBash scripts can be executed from files stored with the build source by using the \u003ccode\u003eargs\u003c/code\u003e field, with the option to set an \u003ccode\u003eentrypoint\u003c/code\u003e to \u003ccode\u003ebash\u003c/code\u003e if necessary.\u003c/p\u003e\n"],["\u003cp\u003eYou can run inline bash commands by specifying \u003ccode\u003ebash\u003c/code\u003e as the \u003ccode\u003ename\u003c/code\u003e in a build step and listing commands in the \u003ccode\u003eargs\u003c/code\u003e field, or using an \u003ccode\u003eentrypoint\u003c/code\u003e in conjunction with bash.\u003c/p\u003e\n"]]],[],null,["# Running bash scripts\n\nThis page explains how to configure Cloud Build to run bash scripts\nwithin a build step. If you're new to Cloud Build, read the\n[quickstarts](/build/docs/quickstarts) and the\n[Build configuration overview](/build/docs/build-config) first.\n\nYou can run bash scripts within a build step to configure a number of workflows\nincluding:\n\n- Running multiple commands in one build step.\n- Reading from the filesystem.\n- Building in logic such as retries or conditionals.\n- Outputting to the log, for example, running `echo $VARNAME`.\n\nUsing the `script` field\n------------------------\n\nCloud Build provides a `script` field that you can use to specify\nshell scripts to execute in a build step. The `script` field takes a single string\nvalue.\n\nYou can prefix the string value with a [shebang](https://en.wikipedia.org/wiki/Shebang_%28Unix%29)\nto specify the shell to interpret the script. For example, add `#!/usr/bin/env bash` to [specify the Bash shell](https://hub.docker.com/_/bash). 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.\n\nIf you specify `script` in a build step, you cannot specify `args` or `entrypoint`\nin the same step.\n\nThe following snippet demonstrates the `script` field: \n\n### YAML\n\n steps:\n - name: 'bash'\n script: |\n #!/usr/bin/env bash\n echo \"Hello World\"\n - name: 'ubuntu'\n script: echo hello\n - name: 'python'\n script: |\n #!/usr/bin/env python\n print('hello from python')\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"bash\",\n \"script\": \"#!/usr/bin/env bash echo 'Hello World'\"\n },\n {\n \"name\": \"ubuntu\",\n \"script\": \"echo hello\"\n },\n {\n \"name\": \"python\",\n \"script\": \"#!/usr/bin/env python\\nprint('hello from python')\\n\"\n }\n ]\n }\n\nUsing substitutions with the `script` field\n-------------------------------------------\n\nScripts don't directly support substitutions, but they support environment\nvariables. You can map substitutions to environment variables, either\nautomatically all at once, or manually by defining every environment variable\nyourself.\n\n### Map substitutions automatically\n\n- **At the build level** . To automatically map all the substitutions to\n environment variables, which will be available throughout the entire build,\n set `automapSubstitutions` to `true` as an option at the build level. For\n example, the following build config file shows the user-defined\n substitution `$_USER` and the default substitution `$PROJECT_ID` mapped to\n environment variables:\n\n ### YAML\n\n steps:\n - name: 'ubuntu'\n script: |\n #!/usr/bin/env bash\n echo \"Hello $_USER\"\n - name: 'ubuntu'\n script: |\n #!/usr/bin/env bash\n echo \"Your project ID is $PROJECT_ID\"\n options:\n automapSubstitutions: true\n substitutions:\n _USER: \"Google Cloud\"\n\n ### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"ubuntu\",\n \"script\": \"#!/usr/bin/env bash echo 'Hello $_USER'\"\n },\n {\n \"name\": \"ubuntu\",\n \"script\": \"#!/usr/bin/env bash echo 'Your project ID is $PROJECT_ID'\"\n }\n ],\n \"options\": {\n \"automap_substitutions\": true\n },\n \"substitutions\": {\n \"_USER\": \"Google Cloud\"\n }\n }\n\n- **At the step level** . To automatically map all the substitutions and make\n them available as environment variables in a single step, set the\n `automapSubstitutions` field to `true` in that step. In the following\n example, only the second step will show the substitutions correctly,\n because it's the only one with automatic substitutions mapping enabled:\n\n ### YAML\n\n steps:\n - name: 'ubuntu'\n script: |\n #!/usr/bin/env bash\n echo \"Hello $_USER\"\n - name: 'ubuntu'\n script: |\n #!/usr/bin/env bash\n echo \"Your project ID is $PROJECT_ID\"\n automapSubstitutions: true\n substitutions:\n _USER: \"Google Cloud\"\n\n ### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"ubuntu\",\n \"script\": \"#!/usr/bin/env bash echo 'Hello $_USER'\"\n },\n {\n \"name\": \"ubuntu\",\n \"script\": \"#!/usr/bin/env bash echo 'Your project ID is $PROJECT_ID'\",\n \"automap_substitutions\": true\n }\n ],\n },\n \"substitutions\": {\n \"_USER\": \"Google Cloud\"\n }\n\n Additionally, you can make the substitutions available as environment\n variables in the entire build, then ignore them in one step. Set\n `automapSubstitutions` to `true` at the build level, then set the same\n field to `false` in the step where you want to ignore the substitutions. In\n the following example, even though mapping substitutions is enabled at the\n build level, the project ID will not be printed in the second step, because\n `automapSubstitutions` is set to `false` in that step: \n\n ### YAML\n\n steps:\n - name: 'ubuntu'\n script: |\n #!/usr/bin/env bash\n echo \"Hello $_USER\"\n - name: 'ubuntu'\n script: |\n #!/usr/bin/env bash\n echo \"Your project ID is $PROJECT_ID\"\n automapSubstitutions: false\n options:\n automapSubstitutions: true\n substitutions:\n _USER: \"Google Cloud\"\n\n ### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"ubuntu\",\n \"script\": \"#!/usr/bin/env bash echo 'Hello $_USER'\"\n },\n {\n \"name\": \"ubuntu\",\n \"script\": \"#!/usr/bin/env bash echo 'Your project ID is $PROJECT_ID'\",\n \"automap_substitutions\": false\n }\n ],\n \"options\": {\n \"automap_substitutions\": true\n },\n },\n \"substitutions\": {\n \"_USER\": \"Google Cloud\"\n }\n\n### Map substitutions manually\n\nYou can manually map the substitutions to environment variables. Every\nenvironment variable is defined at the step level using [the `env`\nfield](/build/docs/build-config-file-schema#env), and the scope of the variables is restricted to the step\nwhere they are defined. This field takes a list of keys and values.\n\nThe following example shows how to map the substitution `$PROJECT_ID` to the\nenvironment variable `BAR`: \n\n### YAML\n\n steps:\n - name: 'ubuntu'\n env:\n - 'BAR=$PROJECT_ID'\n script: 'echo $BAR'\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"ubuntu\",\n \"env\": [\n \"BAR=$PROJECT_ID\"\n ],\n \"script\": \"echo $BAR\"\n }\n ]\n }\n\nRunning bash scripts on disk\n----------------------------\n\nIf you have your bash script saved in a file, store the file along with\nyour build source, and reference the script file within your build config file: \n\n### YAML\n\n steps:\n - name: 'bash'\n args: ['./myscript.bash']\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"bash\",\n \"args\": [\n \"./myscript.bash\"\n ]\n }\n ]\n }\n\nTo use a bash script on file if bash is not the default entrypoint of the image\nyou're using, add an `entrypoint` field pointing to bash: \n\n### YAML\n\n steps:\n - name: 'gcr.io/cloud-builders/gcloud'\n entrypoint: 'bash'\n args: ['tools/myScript.sh','--foo']\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"gcr.io/cloud-builders/gcloud\",\n \"entrypoint\": \"bash\",\n \"args\": [\n \"tools/myScript.sh\",\n \"--foo\"\n ]\n }\n ]\n }\n\nRunning inline bash scripts\n---------------------------\n\nTo run bash commands using the `bash` image, specify `bash` as the `name`\nof the build step, and the command in the args field: \n\n### YAML\n\n steps:\n - name: 'bash'\n args: ['echo', 'I am running a bash command']\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"bash\",\n \"args\": [\n \"echo\",\n \"I am running a bash command\"\n ]\n }\n ]\n }\n\nIf the image you're using comes prepackaged with `bash` but if `bash` is not the\ndefault entrypoint, add an `entrypoint` field pointing to `bash`. In the example\nbelow, the `bash` entrypoint is used to run `gcloud` commands that query\nCloud Build for build status, listing builds with a failed status. \n\n### YAML\n\n steps:\n - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'\n entrypoint: 'bash'\n args:\n - '-eEuo'\n - 'pipefail'\n - '-c'\n - |-\n gcloud builds list \u003e builds.txt\n while read line; do\n if grep -q \"FAILURE\" \u003c\u003c\u003c \"$line\"; then\n echo \"$line\"\n fi\n done \u003c builds.txt\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"gcr.io/google.com/cloudsdktool/cloud-sdk\",\n \"entrypoint\": \"bash\",\n \"args\": [\n \"-eEuo\",\n \"pipefail\",\n \"-c\",\n \"gcloud builds list \u003e builds.txt\\nwhile read line; do\\n if grep -q \\\"FAILURE\\\" \u003c\u003c\u003c \\\"$line\\\"; then\\n echo \\\"$line\\\"\\n fi\\ndone \u003c builds.txt\"\n ]\n }\n ]\n }\n\nThe `-c` flag in the code above is used to execute multi-line commands. Any string\nyou pass after `-c` is treated as a command. For more information on running bash\ncommands with `-c`, see the\n[bash documentation](https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Invoking-Bash).\n\nWhat's next\n-----------\n\n- Learn how to [start a build manually](/build/docs/running-builds/start-build-manually).\n- Learn how to [automate builds using triggers](/build/docs/automating-builds/create-manage-triggers).\n- Learn how to [configure build step order](/build/docs/configuring-builds/configure-build-step-order).\n- Learn how to [use community-contributed builders and custom builders](/build/docs/configuring-builds/use-community-and-custom-builders)."]]