빌드 단계가 실행되는 순서를 지정할 수 있습니다. 기본적으로 빌드 단계는 순차적으로 실행되지만 동시에 실행되도록 구성할 수 있습니다.
이 페이지에서는 빌드 단계의 순서를 구성하는 방법을 설명합니다.
빌드 단계 순서 및 종속 항목
빌드 단계의 waitFor 필드를 사용하여 이 단계보다 먼저 실행해야 하는 단계를 지정합니다. waitFor에 지정된 값이 없으면 빌드 단계는 빌드 요청의 모든 이전 빌드 단계가 완료될 때까지 기다린 후에 실행됩니다.
빌드 시 빌드 단계를 즉시 실행하려면 waitFor 필드에 -를 사용합니다.
steps 필드에서 빌드 단계의 순서는 단계가 실행되는 순서와 관련이 있습니다. 단계는 해당 waitFor 필드에 정의된 종속 항목에 따라 순차적으로 또는 동시에 실행됩니다.
단계는 waitFor의 모든 id에 종속적이며 각 종속항목이 성공적으로 완료된 후에 시작됩니다.
선택적 waitFor 필드가 없는 단계(또는 waitFor가 비어 있는 단계)는 모든 이전 단계가 성공적으로 완료될 때까지 기다린 후에 실행됩니다. 따라서 waitFor 필드에 id가 포함된 단계가 없으면 모든 단계가 정의된 순서에 따라 순차적으로 실행됩니다.
waitFor에 -만 포함하면 빌드 시작 시 단계가 실행될 수 있습니다. 단계가 -에만 의존한다고 선언하면 빌드가 시작될 때 즉시 단계가 실행됩니다. 첫 번째로 정의된 단계는 암시적으로 빌드 시작 시 실행됩니다.
다음 스니펫은 두 단계가 연속적으로 실행되는 빌드 구성을 보여줍니다.
YAML
steps:-name:foo-name:bar
JSON
{"steps":[{"name":"foo"},{"name":"bar"}]}
다음 스니펫은 시작에 의존하는 두 가지 동시 단계를 세 번째 단계는 앞의 두 단계가 완료된 후 시작됩니다. 이 동시 빌드는 빌드 시작 시 단계 A와 B를 실행합니다. 세 번째 단계는 이전의 두 단계가 완료될 때까지 암시적으로 대기한 후 시작됩니다. 이 예시는 후속 waitFor에서 참조되지 않는 id 필드를 누락하여 간소화할 수 있습니다.
다음 스니펫은 이전 단계에 의존하는 동시 단계를 보여줍니다. 단계 A는 빌드가 시작될 때 즉시 실행됩니다. 단계 B와 C는 A가 성공적으로 완료된 후에 동시에 실행됩니다. 실행 순서를 변경하지 않고 B 단계의 id 및 waitFor 필드와 C 단계의 id 필드를 누락할 수 있습니다.
아래 예시에서는 gsutil 및 wget 단계를 동시에 호출합니다.
이 단계가 완료되면 ubuntu 단계가 호출됩니다.
YAML
steps:# Download the binary and the data in parallel.-name:'gcr.io/cloud-builders/wget'args:['https://example.com/binary']-name:'gcr.io/cloud-builders/gsutil'args:['cp','gs://$PROJECT_ID-data/rawdata.tgz','.']waitFor:['-']# The '-' indicates that this step begins immediately.# Run the binary on the data, once both are downloaded.-name:'ubuntu'args:['./binary','rawdata.tgz']
아래 예시에서는 id 필드를 사용하여 특정 빌드 단계를 식별합니다. id의 값은 waitFor에서 빌드 단계 순서를 정의하기 위해 사용됩니다.
먼저 fetch-resources 단계는 gsutil을 사용하여 Cloud Storage에서 로컬 리소스를 복사합니다. 이와 동시에 go가 소스 코드를 생성, 테스트, 설치합니다.
그런 다음 다른 모든 단계가 완료된 후에 docker 빌드 단계가 이미지를 빌드합니다.
YAML
steps:-name:'gcr.io/cloud-builders/go'args:['generate']-name:'gcr.io/cloud-builders/go'args:['test','./...']-name:'gcr.io/cloud-builders/go'args:['install','mytarget']id:'go-install'-name:'gcr.io/cloud-builders/gsutil'args:['cp','-r','./somefiles','gs://my-resource-bucket/somefiles']waitFor:['-']# The '-' indicates that this step begins immediately.id:'fetch-resources'-name:'gcr.io/cloud-builders/docker'args:['build','-t','gcr.io/$PROJECT_ID/mytarget','.']waitFor:['go-install','fetch-resources']images:['gcr.io/$PROJECT_ID/mytarget']
[[["이해하기 쉬움","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\u003eBuild steps can be configured to run sequentially or concurrently using the \u003ccode\u003ewaitFor\u003c/code\u003e field.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003ewaitFor\u003c/code\u003e field specifies which steps must complete before a given step begins, and an empty \u003ccode\u003ewaitFor\u003c/code\u003e or absence of this field means a step will wait for all prior steps to finish.\u003c/p\u003e\n"],["\u003cp\u003eUsing \u003ccode\u003e-\u003c/code\u003e in the \u003ccode\u003ewaitFor\u003c/code\u003e field will cause a build step to run immediately when the build starts.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eid\u003c/code\u003e field allows you to define a unique identifier for a step, which can then be referenced in other steps' \u003ccode\u003ewaitFor\u003c/code\u003e fields to establish dependencies.\u003c/p\u003e\n"],["\u003cp\u003eIf no \u003ccode\u003eid\u003c/code\u003e values are specified in the \u003ccode\u003ewaitFor\u003c/code\u003e field of any steps, all build steps will run sequentially, in the order they are defined.\u003c/p\u003e\n"]]],[],null,["# Configuring the order of build steps\n\nYou can specify the order in which your build steps are executed. By default,\nbuild steps run sequentially, but you can configure them to run concurrently.\n\nThis page explains how to configure the order of the build steps.\n\n### Build step order and dependencies\n\nUse the `waitFor` field in a build step to specify which steps *must run* before\nthe build step is run. If no values are provided for `waitFor`, the build step\nwaits for *all prior* build steps in the build request to complete successfully\nbefore running.\n\nTo run a build step *immediately* at build time, use `-` in the `waitFor` field.\n\nThe order of the build steps in the `steps` field relates to the order in which\nthe steps are executed. Steps will run serially or concurrently based on the\ndependencies defined in their `waitFor` fields.\n\nA step is dependent on every `id` in its `waitFor` and will not launch until\neach dependency has completed successfully.\n| **Note:** Steps must be defined with the `id` field prior to being used as `waitFor` dependencies.\n\nSteps without the optional `waitFor` field (or with an empty `waitFor`) will\nwait for *all prior steps to complete successfully* before executing. Therefore,\nif no step contains an `id` in its `waitFor` field, then all steps will *execute\nserially in the order they are defined*.\n\nSteps can depend on the start of the build by having `waitFor` contain only\n`-`. By declaring that a step depends only on `-`, the step *runs immediately\nwhen the build starts*. The first step defined depends implicitly on start.\n\nThe following snippet shows a build config with two steps that runs serially: \n\n### YAML\n\n steps:\n - name: foo\n - name: bar\n\n### JSON\n\n {\n \"steps\": [{\n \"name\": \"foo\"\n },\n {\n \"name\": \"bar\"\n }\n ]\n }\n\nThe following snippet shows two concurrent steps that both depend on start; the\nthird step waits for the first two to complete successfully before\nlaunching. This concurrent build runs steps `A` and `B` at the start of the\nbuild. The third step will wait implicitly until both previous steps are\nfinished before starting. This example could be simplified by omitting the `id`\nfields, which are not referenced in a subsequent `waitFor`. \n\n### YAML\n\n steps:\n - name: foo\n id: A\n - name: bar\n id: B\n waitFor: ['-']\n - name: baz\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"foo\",\n \"id\": \"A\"\n },\n {\n \"name\": \"bar\",\n \"id\": \"B\",\n \"waitFor\": [\"-\"]\n },\n {\n \"name\": \"baz\"\n }\n ]\n }\n\nThe following snippet shows concurrent steps that depend on a previous\nstep. Step `A` runs immediately when the build starts. Steps `B` and `C` run\nconcurrently after `A` has completed successfully. Note that the `id` and\n`waitFor` fields in step `B`, and the `id` field in step `C`, could be omitted\nwithout changing the order of execution. \n\n### YAML\n\n steps:\n - name: foo\n id: A\n - name: bar\n id: B\n waitFor:\n - A\n - name: baz\n id: C\n waitFor:\n - A\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"foo\",\n \"id\": \"A\"\n },\n {\n \"name\": \"bar\",\n \"id\": \"B\",\n \"waitFor\": [\n \"A\"\n ]\n },\n {\n \"name\": \"baz\",\n \"id\": \"C\",\n \"waitFor\": [\n \"A\"\n ]\n }\n ]\n }\n\nExamples\n--------\n\nThe example below calls the `gsutil` and `wget` steps concurrently.\nAfter these steps have completed, the `ubuntu` step is called. \n\n### YAML\n\n steps:\n # Download the binary and the data in parallel.\n - name: 'gcr.io/cloud-builders/wget'\n args: ['https://example.com/binary']\n - name: 'gcr.io/cloud-builders/gsutil'\n args: ['cp', 'gs://$PROJECT_ID-data/rawdata.tgz', '.']\n waitFor: ['-'] # The '-' indicates that this step begins immediately.\n\n # Run the binary on the data, once both are downloaded.\n - name: 'ubuntu'\n args: ['./binary', 'rawdata.tgz']\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"gcr.io/cloud-builders/wget\",\n \"args\": [\n \"https://example.com/binary\"\n ]\n },\n {\n \"name\": \"gcr.io/cloud-builders/gsutil\",\n \"args\": [\n \"cp\",\n \"gs://$PROJECT_ID-data/rawdata.tgz\",\n \".\"\n ],\n \"waitFor\": [\n \"-\"\n ]\n },\n {\n \"name\": \"ubuntu\",\n \"args\": [\n \"./binary\",\n \"rawdata.tgz\"\n ]\n }\n ]\n }\n\nThe example below uses the `id` field to identify certain build steps. The values\nfrom `id` are used in `waitFor` to define build step order:\n\n- First, `fetch-resources` step uses `gsutil` to copy the local resources from Cloud Storage. Concurrently, `go` generates, tests, and installs the source code.\n- Then, the `docker` build step builds the image after all other steps are\n complete.\n\n### YAML\n\n steps:\n - name: 'gcr.io/cloud-builders/go'\n args: ['generate']\n - name: 'gcr.io/cloud-builders/go'\n args: ['test', './...']\n - name: 'gcr.io/cloud-builders/go'\n args: ['install', 'mytarget']\n id: 'go-install'\n\n - name: 'gcr.io/cloud-builders/gsutil'\n args: ['cp', '-r', './somefiles', 'gs://my-resource-bucket/somefiles']\n waitFor: ['-'] # The '-' indicates that this step begins immediately.\n id: 'fetch-resources'\n\n - name: 'gcr.io/cloud-builders/docker'\n args: ['build', '-t', 'gcr.io/$PROJECT_ID/mytarget', '.']\n waitFor: ['go-install', 'fetch-resources']\n\n images: ['gcr.io/$PROJECT_ID/mytarget']\n\n### JSON\n\n {\n \"steps\": [\n {\n \"name\": \"gcr.io/cloud-builders/go\",\n \"args\": [\n \"generate\"\n ]\n },\n {\n \"name\": \"gcr.io/cloud-builders/go\",\n \"args\": [\n \"test\",\n \"./...\"\n ]\n },\n {\n \"name\": \"gcr.io/cloud-builders/go\",\n \"args\": [\n \"install\",\n \"mytarget\"\n ],\n \"id\": \"go-install\"\n },\n {\n \"name\": \"gcr.io/cloud-builders/gsutil\",\n \"args\": [\n \"cp\",\n \"-r\",\n \"./somefiles\",\n \"gs://my-resource-bucket/somefiles\"\n ],\n \"waitFor\": [\n \"-\"\n ],\n \"id\": \"fetch-resources\"\n },\n {\n \"name\": \"gcr.io/cloud-builders/docker\",\n \"args\": [\n \"build\",\n \"-t\",\n \"gcr.io/$PROJECT_ID/mytarget\",\n \".\"\n ],\n \"waitFor\": [\n \"go-install\",\n \"fetch-resources\"\n ]\n }\n ],\n \"images\": [\n \"gcr.io/$PROJECT_ID/mytarget\"\n ]\n }\n\nWhat's next\n-----------\n\n- Configure Cloud Build to [build, test, and deploy\n artifacts](/build/docs/configuring-builds/build-test-deploy-artifacts).\n- Learn how to run builds [manually](/build/docs/running-builds/start-build-manually) and using [triggers](/build/docs/running-builds/automate-builds)."]]