

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# CodeBuild의 빌드 사양 참조
<a name="build-spec-ref"></a>

이 주제에서는 빌드 사양(buildspec) 파일에 대한 중요한 참조 정보를 제공합니다. *buildspec*은 CodeBuild가 빌드를 실행하는 데 사용하는 YAML 형식의 빌드 명령 및 관련 설정의 모음입니다. 소스 코드의 일부로 buildspec을 포함하거나, 빌드 프로젝트를 생성할 때 buildspec을 정의할 수 있습니다. 빌드 사양의 작동 방식에 대한 자세한 정보는 [CodeBuild 작동 방식](concepts.md#concepts-how-it-works) 단원을 참조하십시오.

**Topics**
+ [buildspec 파일 이름 및 스토리지 위치](#build-spec-ref-name-storage)
+ [buildspec 구문](#build-spec-ref-syntax)
+ [buildspec 예제](#build-spec-ref-example)
+ [buildspec 버전](#build-spec-ref-versions)
+ [배치 빌드 buildspec 참조](batch-build-buildspec.md)

## buildspec 파일 이름 및 스토리지 위치
<a name="build-spec-ref-name-storage"></a>

buildspec을 소스 코드의 일부로 포함하는 경우, 기본적으로 buildspec 파일에 `buildspec.yml`이라는 이름을 지정해야 하며 이 파일을 소스 디렉터리의 루트에 배치해야 합니다.

기본 buildspec 파일 이름과 위치를 재정의할 수 있습니다. 예를 들어, 다음을 수행할 수 있습니다.
+ 동일한 리포지토리의 다른 빌드에 대해 `buildspec_debug.yml` 및 `buildspec_release.yml`과 같은 다른 buildspec 파일을 사용합니다.
+ buildspec 파일을 `config/buildspec.yml`과 같은 소스 디렉터리의 루트가 아닌 다른 위치 또는 S3 버킷에 저장합니다. S3 버킷은 빌드 프로젝트와 동일한 AWS 리전에 있어야 합니다. ARN을 사용하여 buildspec 파일을 지정합니다(예: `arn:aws:s3:::<my-codebuild-sample2>/buildspec.yml`).

buildspec 파일의 이름과 상관없이, 한 빌드 프로젝트에 대해 하나의 buildspec만 지정할 수 있습니다.

기본 buildspec 파일 이름이나 위치 또는 둘 다를 재정의하려면 다음 중 하나를 수행합니다.
+ 또는 `update-project` 명령을 실행 AWS CLI `create-project`하여 기본 제공 환경 변수의 `buildspec` 값을 기준으로 대체 buildspec 파일의 경로로 값을 설정합니다`CODEBUILD_SRC_DIR`. SDK에서 `create project` 작업과 동등한 작업을 수행할 수도 있습니다. AWS SDKs 자세한 내용은 [빌드 프로젝트 생성](create-project.md) 또는 [빌드 프로젝트 설정 변경](change-project.md)을 참조하세요.
+ 명령을 실행 AWS CLI `start-build`하여 기본 제공 환경 변수의 `buildspecOverride` 값을 기준으로 대체 buildspec 파일의 경로로 값을 설정합니다`CODEBUILD_SRC_DIR`. SDK에서 `start build` 작업과 동등한 작업을 수행할 수도 있습니다. AWS SDKs 자세한 내용은 [빌드를 수동으로 실행](run-build.md) 단원을 참조하십시오.
+  AWS CloudFormation 템플릿에서 유형의 리소스`Source`에 있는의 `BuildSpec` 속성을 기본 제공 환경 변수의 값을 기준으로 대체 buildspec 파일의 `AWS::CodeBuild::Project` 경로로 설정합니다`CODEBUILD_SRC_DIR`. 자세한 내용은AWS CloudFormation 사용 설명서의 [AWS CodeBuild 프로젝트 소스](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-codebuild-project-source.html)에서 BuildSpec 속성을 참조하세요.**

## buildspec 구문
<a name="build-spec-ref-syntax"></a>

buildspec 파일은 [YAML](http://yaml.org/) 형식으로 표시해야 합니다.

명령에 YAML에서 지원하지 않는 문자 또는 문자열이 포함된 경우 명령을 따옴표("")로 묶어야 합니다. YAML에서는 콜론(:) 뒤에 공백이 올 수 없으므로 다음 명령을 따옴표로 묶습니다. 명령의 따옴표는 이스케이프(\$1")됩니다.

```
"export PACKAGE_NAME=$(cat package.json | grep name | head -1 | awk -F: '{ print $2 }' | sed 's/[\",]//g')"
```

buildspec 구문은 다음과 같습니다.

```
version: 0.2

run-as: Linux-user-name

env:
  shell: shell-tag
  variables:
    key: "value"
    key: "value"
  parameter-store:
    key: "value"
    key: "value"
  exported-variables:
    - variable
    - variable
  secrets-manager:
    key: secret-id:json-key:version-stage:version-id
  git-credential-helper: no | yes

proxy:
  upload-artifacts: no | yes
  logs: no | yes

batch:
  fast-fail: false | true
  # build-list:
  # build-matrix:
  # build-graph:
  # build-fanout:
        
phases:
  install:
    run-as: Linux-user-name
    on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex
    runtime-versions:
      runtime: version
      runtime: version
    commands:
      - command
      - command
    finally:
      - command
      - command
    
  pre\$1build:
    run-as: Linux-user-name
    on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex
    commands:
      - command
      - command
    finally:
      - command
      - command
    
  build:
    run-as: Linux-user-name
    on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex
    commands:
      - command
      - command
    finally:
      - command
      - command
    
  post\$1build:
    run-as: Linux-user-name
    on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex
    commands:
      - command
      - command
    finally:
      - command
      - command
    
reports:
  report-group-name-or-arn:
    files:
      - location
      - location
    base-directory: location
    discard-paths: no | yes
    file-format: report-format
artifacts:
  files:
    - location
    - location
  name: artifact-name
  discard-paths: no | yes
  base-directory: location
  exclude-paths: excluded paths
  enable-symlinks: no | yes
  s3-prefix: prefix
  secondary-artifacts:
    artifactIdentifier:
      files:
        - location
        - location
      name: secondary-artifact-name
      discard-paths: no | yes
      base-directory: location
    artifactIdentifier:
      files:
        - location
        - location
      discard-paths: no | yes
      base-directory: location
cache:
  key: key
  fallback-keys:
    - fallback-key
    - fallback-key
  action: restore | save
  paths:
    - path
    - path
```

buildspec에는 다음이 포함됩니다.

### 버전
<a name="build-spec.version"></a>

필수 매핑. buildspec 버전을 나타냅니다. `0.2`을 사용할 것을 권장합니다.

**참고**  
버전 0.1도 계속 지원되지만 가능하면 버전 0.2를 사용할 것을 권장합니다. 자세한 내용은 [buildspec 버전](#build-spec-ref-versions) 단원을 참조하십시오.

### run-as
<a name="build-spec.run-as"></a>

선택적 시퀀스. Linux 사용자만 사용할 수 있습니다. 이 buildspec 파일의 명령을 실행하는 Linux 사용자를 지정합니다. `run-as`는 지정한 사용자에게 읽기 및 실행 권한을 부여합니다. buildspec 파일 처음에 `run-as`를 지정할 경우 모든 명령에 전역적으로 적용됩니다. 모든 buildspec 파일 명령에 대한 사용자를 지정하지 않으려는 경우 `phases` 블록 중 하나에 `run-as`를 사용하여 단계에 명령에 대한 사용자를 지정할 수 있습니다. `run-as`를 지정하지 않으면 모든 명령이 루트 사용자로 실행됩니다.

### env
<a name="build-spec.env"></a>

선택적 시퀀스. 하나 이상의 사용자 지정 환경 변수에 대한 정보를 나타냅니다.

**참고**  
 중요한 정보를 보호하기 위해 CodeBuild 로그에 다음 항목이 숨겨져 있습니다.  
 AWS 액세스 키 IDs. 자세한 내용은AWS Identity and Access Management 사용 설명서에서 [IAM 사용자의 액세스 키 관리](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)를 참조하세요.**
 파라미터 스토어를 사용하여 지정된 문자열입니다. 자세한 내용은 Amazon EC2 Systems Manager 사용 설명서의 [Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) 및 [Systems Manager Parameter Store 콘솔 연습](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-walk.html#sysman-paramstore-console)을 참조하세요.**
 를 사용하여 지정된 문자열입니다 AWS Secrets Manager. 자세한 내용은 [키 관리](security-key-management.md) 단원을 참조하십시오.

env/**shell**  <a name="build-spec.shell"></a>
선택적 시퀀스. Linux 또는 Windows 운영 체제에서 지원되는 쉘을 지정합니다.  
Linux 운영 체제의 경우 지원되는 쉘 태그는 다음과 같습니다.  
+ `bash`
+ `/bin/sh`
Windows 운영 체제의 경우 지원되는 쉘 태그는 다음과 같습니다.  
+ `powershell.exe`
+ `cmd.exe`

env/**variables**  <a name="build-spec.env.variables"></a>
`env`가 지정된 경우 및 사용자 지정 환경 변수를 일반 텍스트로 정의하려고 할 때 필요합니다. *key*/*value* 스칼라 매핑을 포함하며, 각 매핑은 일반 텍스트의 단일 사용자 지정 환경 변수를 나타냅니다. *key*는 사용자 지정 환경 변수의 이름이고, *value*는 이 변수의 값입니다.  
중요한 값을 환경 변수에 저장하지 마세요. 환경 변수는 CodeBuild 콘솔 및 AWS CLI와 같은 도구를 사용하여 일반 텍스트로 표시할 수 있습니다. 이 단원의 뒷부분에서 설명하는 것처럼 중요한 값의 경우 `parameter-store` 또는 `secrets-manager` 매핑을 사용하는 것이 좋습니다.  
사용자가 설정한 환경 변수는 기존 환경 변수를 대체합니다. 예를 들어 도커 이미지에 값이 `my_value`인 `MY_VAR`이라는 환경 변수가 이미 포함되어 있는데, 사용자가 `MY_VAR` 환경 변수의 값을 `other_value`로 설정하면, `my_value`가 `other_value`로 바뀝니다. 마찬가지로, 도커 이미지에 값이 `/usr/local/sbin:/usr/local/bin`인 `PATH`라는 환경 변수가 이미 포함되어 있는데, 사용자가 `PATH` 환경 변수의 값을 `$PATH:/usr/share/ant/bin`으로 설정하면, `/usr/local/sbin:/usr/local/bin`이 `$PATH:/usr/share/ant/bin` 리터럴 값으로 바뀝니다.  
`CODEBUILD_`로 시작하는 이름으로 환경 변수를 설정하지 마십시오. 이 접두사는 내부 전용으로 예약되어 있습니다.  
여러 위치에서 동일한 이름의 환경 변수가 정의되는 경우, 다음과 같이 값이 결정됩니다.  
+ 시작 빌드 작업 호출의 값이 가장 높은 우선 순위를 갖습니다. 빌드를 생성할 때 환경 변수를 추가 또는 재정의할 수 있습니다. 자세한 내용은 [수동으로 AWS CodeBuild 빌드 실행](run-build.md) 단원을 참조하십시오.
+ 빌드 프로젝트 정의의 값이 다음 우선 순위를 갖습니다. 프로젝트를 생성 또는 편집할 때 프로젝트 수준에서 환경 변수를 추가할 수 있습니다. 자세한 내용은 [에서 빌드 프로젝트 생성AWS CodeBuild](create-project.md) 및 [에서 빌드 프로젝트 설정 변경 AWS CodeBuild](change-project.md) 섹션을 참조하세요.
+ buildspec 선언의 값이 가장 낮은 우선 순위를 갖습니다.

env/**parameter-store**  <a name="build-spec.env.parameter-store"></a>
`env`가 지정되었으며 Amazon EC2 Systems Manager Parameter Store에 저장된 사용자 지정 환경 변수를 검색하려고 할 때 필요합니다. *key*/*value* 스칼라 매핑을 포함하며, 각 매핑은 Amazon EC2 Systems Manager Parameter Store에 저장된 하나의 사용자 지정 환경 변수를 나타냅니다. *key*는 이 사용자 지정 환경 변수를 참조하기 위해 나중에 빌드 명령에서 사용할 이름이고, *value*는 Amazon EC2 Systems Manager Parameter Store에 저장되는 사용자 지정 환경 변수의 이름입니다. 중요한 값을 저장하려면 Amazon EC2 Systems Manager 사용 설명서의 [Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) 및 [안내: 문자열 파라미터 생성 및 테스트(콘솔)](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-console.html)를 참조하세요.**  
CodeBuild가 Amazon EC2 Systems Manager Parameter Store에 저장된 사용자 지정 환경 변수를 검색하도록 허용하려면 `ssm:GetParameters` 작업을 CodeBuild 서비스 역할에 추가해야 합니다. 자세한 내용은 [CodeBuild가 다른 AWS 서비스와 상호 작용하도록 허용](setting-up-service-role.md) 단원을 참조하십시오.  
Amazon EC2 Systems Manager Parameter Store에서 검색하는 환경 변수는 기존 환경 변수를 대체합니다. 예를 들어 도커 이미지에 값이 `MY_VAR`인 `my_value`이라는 환경 변수가 이미 포함되어 있는데, 사용자가 `MY_VAR` 환경 변수의 값을 `other_value`로 검색하면, `my_value`가 `other_value`로 바뀝니다. 마찬가지로, 도커 이미지에 값이 `PATH`인 `/usr/local/sbin:/usr/local/bin`라는 환경 변수가 이미 포함되어 있는데, 사용자가 `PATH` 환경 변수의 값을 `$PATH:/usr/share/ant/bin`으로 검색하면, `/usr/local/sbin:/usr/local/bin`이 `$PATH:/usr/share/ant/bin` 리터럴 값으로 바뀝니다.  
`CODEBUILD_`로 시작하는 이름으로 환경 변수를 저장하지 마십시오. 이 접두사는 내부 전용으로 예약되어 있습니다.  
여러 위치에서 동일한 이름의 환경 변수가 정의되는 경우, 다음과 같이 값이 결정됩니다.  
+ 시작 빌드 작업 호출의 값이 가장 높은 우선 순위를 갖습니다. 빌드를 생성할 때 환경 변수를 추가 또는 재정의할 수 있습니다. 자세한 내용은 [수동으로 AWS CodeBuild 빌드 실행](run-build.md) 단원을 참조하십시오.
+ 빌드 프로젝트 정의의 값이 다음 우선 순위를 갖습니다. 프로젝트를 생성 또는 편집할 때 프로젝트 수준에서 환경 변수를 추가할 수 있습니다. 자세한 내용은 [에서 빌드 프로젝트 생성AWS CodeBuild](create-project.md) 및 [에서 빌드 프로젝트 설정 변경 AWS CodeBuild](change-project.md) 섹션을 참조하세요.
+ buildspec 선언의 값이 가장 낮은 우선 순위를 갖습니다.

env/**secrets-manager**  <a name="build-spec.env.secrets-manager"></a>
에 저장된 사용자 지정 환경 변수를 검색하려는 경우 필요합니다 AWS Secrets Manager. 다음 패턴을 사용하여 Secrets Manager `reference-key`를 지정합니다.  
`<key>`: `<secret-id>:<json-key>:<version-stage>:<version-id>`    
*<key>*  
(필수) 로컬 환경 변수 이름입니다. 이 이름을 사용하면 빌드 중에 변수에 액세스할 수 있습니다.  
*<secret-id>*  
(필수) 보안 암호에 대한 고유 식별자 역할을 하는 이름 또는 Amazon 리소스 이름(ARN)입니다. AWS 계정에 있는 암호에 액세스하려면 암호 이름을 지정합니다. 다른 AWS 계정의 보안 암호에 액세스하려면 보안 암호 ARN을 지정합니다.  
*<json-key>*  
(선택 사항) 해당 값을 검색하려는 Secrets Manager 키-값 페어의 키 이름을 지정합니다. `json-key`를 지정하지 않는 경우 CodeBuild에서 전체 보안 암호 텍스트를 검색합니다.  
*<version-stage>*  
(선택 사항) 버전에 연결된 레이블을 스테이징하여 검색하려는 보안 암호 버전을 지정합니다. 스테이징 레이블은 교체 프로세스 도중 다른 버전을 추적하는 데 사용됩니다. `version-stage`를 사용하는 경우 `version-id`를 지정하지 마십시오. 버전 스테이지 또는 버전 ID를 지정하지 않으면 기본값은 `AWSCURRENT`의 버전 스테이지 값으로 버전을 검색하는 것입니다.  
*<version-id>*  
(선택 사항) 사용하려는 암호의 버전에 대한 고유 식별자를 지정합니다. `version-id`을 지정할 경우 `version-stage`을 지정하지 마십시오. 버전 스테이지 또는 버전 ID를 지정하지 않으면 기본값은 `AWSCURRENT`의 버전 스테이지 값으로 버전을 검색하는 것입니다.
다음 예제에서 `TestSecret`은 Secrets Manager에 저장되는 키-값 페어의 이름입니다. `TestSecret`의 키는 `MY_SECRET_VAR`입니다. 빌드 중에 `LOCAL_SECRET_VAR` 이름을 사용하여 변수에 액세스합니다.  

```
env:
  secrets-manager:
    LOCAL_SECRET_VAR: "TestSecret:MY_SECRET_VAR"
```
자세한 내용은AWS Secrets Manager 사용 설명서에서 [AWS Secrets Manager란 무엇입니까?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 단원을 참조하세요.**

env/**exported-variables**  <a name="build-spec.env.exported-variables"></a>
선택적 매핑. 내보낼 환경 변수를 나열하는 데 사용됩니다. `exported-variables`에서 별도의 행에 내보낼 각 변수의 이름을 지정합니다. 내보낼 변수는 빌드 중에 컨테이너에서 사용할 수 있어야 합니다. 내보내는 변수는 환경 변수일 수 있습니다.  
내보낸 환경 변수는와 함께 현재 빌드 단계에서 파이프라인의 후속 단계로 환경 변수를 AWS CodePipeline 내보내는 데 사용됩니다. 자세한 내용을 알아보려면AWS CodePipeline 사용 설명서의 [변수 작업](https://docs.aws.amazon.com//codepipeline/latest/userguide/actions-variables.html)을 참조하세요.**  
빌드하는 동안 변수의 값은 `install` 단계부터 사용할 수 있습니다. 이 값은 `install` 단계 시작과 `post_build` 단계 끝 사이에서 업데이트할 수 있습니다. `post_build` 단계가 끝나면 내보낸 변수의 값을 변경할 수 없습니다.  
 다음은 내보낼 수 없습니다.  
+  빌드 프로젝트에서 지정된 Amazon EC2 Systems Manager Parameter Store 보안 암호 
+  빌드 프로젝트에서 지정된 Secrets Manager 보안 암호 
+  `AWS_`로 시작하는 환경 변수 

env/**git-credential-helper**  <a name="build-spec.env.git-credential-helper"></a>
선택적 매핑. CodeBuild가 Git 보안 인증 도우미를 사용하여 Git 보안 인증을 제공하는지를 나타내는 데 사용됩니다. Git 보안 인증 도우미가 사용되는 경우 `yes`입니다. 그렇지 않은 경우 `no`이거나 값이 지정되지 않은 것입니다. 자세한 내용은 Git 웹사이트의 [gitcredentials](https://git-scm.com/docs/gitcredentials)를 참조하십시오.  
 퍼블릭 Git 리포지토리에 대해 webhook에서 트리거한 빌드의 경우에는 `git-credential-helper`가 지원되지 않습니다.

### proxy
<a name="build-spec.proxy"></a>

선택적 시퀀스. 명시적 프록시 서버에서 빌드를 실행할 경우 설정을 나타내는 데 사용됩니다. 자세한 내용은 [명시적 프록시 서버에서 CodeBuild 실행](run-codebuild-in-explicit-proxy-server.md) 단원을 참조하십시오.

proxy/**upload-artifacts**  <a name="build-spec.proxy.upload-artifacts"></a>
선택적 매핑. 명시적 프록시 서버에서 빌드가 아티팩트를 업로드하도록 하려면 `yes`로 설정합니다. 기본값은 `no`입니다.

proxy/**logs**  <a name="build-spec.proxy.logs"></a>
선택적 매핑. 명시적 프록시 서버에서 빌드에 대해 `yes`로 설정하여 CloudWatch 로그를 생성합니다. 기본값은 `no`입니다.

### 단계
<a name="build-spec.phases"></a>

필수 시퀀스. 빌드의 각 단계 동안 CodeBuild가 실행하는 명령을 나타냅니다.

**참고**  
buildspec 버전 0.1에서 CodeBuild는 빌드 환경에 있는 기본 쉘의 개별 인스턴스에서 각 명령을 실행합니다. 즉, 각 명령이 다른 모든 명령과 독립적으로 실행됩니다. 따라서 기본적으로 이전 명령의 상태에 따라 실행되는 단일 명령을 실행할 수 없습니다(예: 디렉터리 변경 또는 환경 변수 설정). 이 제한 사항을 해결하려면 이 문제를 해결하는 버전 0.2를 사용하는 것이 좋습니다. buildspec 버전 0.1을 사용해야 하는 경우 [빌드 환경의 쉘 및 명령](build-env-ref-cmd.md) 단원의 접근 방식을 따르는 것이 좋습니다.

phases/\$1/**run-as**  <a name="build-spec.phases.run-as"></a>
선택적 시퀀스. 해당 명령을 실행하는 Linux 사용자를 지정하려면 빌드 단계에 사용합니다. buildspec 파일의 상단에 모든 명령에 대해 전역적으로 `run-as`도 지정할 경우 단계 수준 사용자가 우선 적용됩니다. 예를 들어 전체적으로 `run-as`에서 User-1을 지정하고 해당 `install` 단계에 대해서만 `run-as` 명령문이 User-2를 지정하는 경우, 해당 `install` 단계의 명령이 User-2로 실행되는 것을 *제외하고* buildspec 파일의 모든 명령은 User-1으로 실행됩니다.

phases/\$1/**on-failure**  <a name="build-spec.phases.on-failure"></a>
선택적 시퀀스. 단계 중에 오류가 발생할 경우 수행할 작업을 지정합니다. 다음 값 중 하나일 수 있습니다:  
+ `ABORT` - 빌드를 중단합니다.
+ `CONTINUE` - 다음 단계를 계속 진행합니다.
+ `RETRY` - 정규식 `.*`과 일치하는 오류 메시지와 함께 빌드를 최대 3회 재시도합니다.
+ `RETRY-count` - 정규식 `.*`과 일치하는 오류 메시지와 함께 *수*에 표시된 대로 지정된 횟수만큼 빌드를 재시도합니다. *수*는 0에서 100 사이여야 합니다. 예를 들어, 유효한 값에는 `RETRY-4` 및 `RETRY-8`이 포함됩니다.
+ `RETRY-regex` - 빌드를 최대 3회 재시도하고 *정규식*을 사용하여 지정된 오류 메시지와 일치하는 정규식을 포함합니다. 예를 들어, 유효한 값에는 `Retry-.*Error: Unable to connect to database.*` 및 `RETRY-invalid+`이 포함됩니다.
+ `RETRY-count-regex` - *수*에 표시된 대로 지정된 횟수만큼 빌드를 재시도합니다. *수*는 0에서 100 사이여야 합니다. *정규식*을 사용하여 오류 메시지와 일치하는 정규식을 포함할 수도 있습니다. 예를 들어, 유효한 값에는 `Retry-3-.*connection timed out.*` 및 `RETRY-8-invalid+`이 포함됩니다.
이 속성을 지정하지 않으면 오류 프로세스는 [빌드 단계 진행](view-build-details-phases.md)에 표시된 전환 단계를 따릅니다.  
Lambda 컴퓨팅 또는 예약 용량을 사용할 때는 `on-failure` 속성이 지원되지 않습니다. 이 속성은 CodeBuild에서 제공하는 EC2 컴퓨팅 이미지에서만 작동합니다.

phases/\$1/**finally**  <a name="build-spec.phases.finally"></a>
선택적 블록. `finally` 블록에 지정된 명령은 `commands` 블록의 명령 후에 실행됩니다. `finally` 블록의 명령은 `commands` 블록의 명령이 실패할 경우에도 실행됩니다. 예를 들어 명령 3개가 포함된 `commands` 블록에서 첫 번째 명령이 실패할 경우, CodeBuild는 나머지 두 명령을 건너뛰고 `finally` 블록의 명령을 실행합니다. `commands` 및 `finally` 블록의 모든 명령이 성공적으로 실행되면 단계가 성공합니다. 어느 단계의 명령이 하나라도 실패하면 그 단계는 실패합니다.

허용되는 빌드 단계 이름은 다음과 같습니다.

phases/**install**  <a name="build-spec.phases.install"></a>
선택적 시퀀스. 설치 중에 CodeBuild가 실행하는 명령을 나타냅니다(있는 경우). 빌드 환경에서 패키지를 설치하는 경우에만 `install` 단계를 사용하는 것이 좋습니다. 예를 들어, Mocha나 RSpec 같은 코드 테스팅 프레임워크를 설치하기 위해 이 단계를 사용할 수 있습니다.    
phases/install/**runtime-versions**  
<a name="runtime-versions-in-build-spec"></a>선택적 시퀀스. 런타임 버전은 Ubuntu 표준 이미지 5.0 이상 및 Amazon Linux 2 표준 이미지 4.0 이상에서 지원됩니다. 지정된 경우 적어도 하나의 실행 시간이 이 섹션에 포함되어야 합니다. 특정 버전을 사용하여 런타임을 지정하거나, 주 버전 다음에 `.x`를 사용하여 CodeBuild가 주 버전을 해당 최신 부 버전과 함께 사용하도록 지정하거나, 최신 주 버전 및 부 버전을 사용하도록 `latest`합니다(예: `ruby: 3.2`, `nodejs: 18.x` 또는 `java: latest`). 숫자나 환경 변수를 사용하여 실행 시간을 지정할 수 있습니다. 예를 들어 Amazon Linux 2 표준 이미지 4.0을 사용하는 경우 다음은 Java 버전 17, Python 버전 3의 최신 부 버전, Ruby 환경 변수에 포함된 버전이 설치되도록 지정합니다. 자세한 내용은 [CodeBuild가 제공하는 도커 이미지](build-env-ref-available.md) 단원을 참조하십시오.  

```
phases:
  install:
    runtime-versions:
      java: corretto8
      python: 3.x
      ruby: "$MY_RUBY_VAR"
```
빌드 사양 파일의 `runtime-versions` 섹션에서 하나 이상의 런타임을 지정할 수 있습니다. 런타임이 다른 런타임에 종속되는 경우 빌드 사양 파일에서 종속 런타임을 지정할 수도 있습니다. buildspec 파일에 런타임을 지정하지 않은 경우 CodeBuild에서는 사용하는 이미지에서 사용할 수 있는 기본 런타임을 선택합니다. 하나 이상의 런타임을 지정하는 경우 CodeBuild에서는 해당 런타임만 사용합니다. 종속 런타임을 지정하지 않은 경우 CodeBuild에서 종속 런타임을 선택하려고 시도합니다.  
런타임 버전이 지정되지 않은 경우 CodeBuild는 기본 버전을 사용합니다. 이전 기본 버전이 수명 종료(EOL)에 도달하면 기본 버전이 변경될 수 있습니다. 빌드 환경이 예기치 않게 변경되지 않도록 buildspec 파일에 런타임 버전을 지정하는 것이 좋습니다.
지정된 두 실행 시간이 충돌하면 빌드가 실패합니다. 예를 들어 `android: 29`와 `java: openjdk11`이 충돌하므로 둘 다 지정하면 빌드가 실패합니다.  
사용 가능한 런타임에 대한 자세한 내용은 [사용 가능한 런타임](available-runtimes.md) 섹션을 참조하세요.  
 `runtime-versions` 섹션을 지정하고 Ubuntu 표준 이미지 2.0 이상 또는 Amazon Linux 2(AL2) 표준 이미지 1.0 이상 외의 이미지를 사용하는 경우, 빌드에서 “`Skipping install of runtimes. Runtime version selection is not supported by this build image`”라는 경고가 발생합니다.  
phases/install/**commands**  
선택적 시퀀스. 스칼라 시퀀스를 포함합니다. 여기서 각 스칼라는 CodeBuild가 설치 중에 실행하는 단일 명령을 나타냅니다. 빌드 단계마다, CodeBuild는 처음부터 끝까지 한 번에 하나씩 나열된 순서로 각 명령을 실행합니다.

phases/**pre\$1build**  <a name="build-spec.phases.pre_build"></a>
선택적 시퀀스. 빌드 전에 CodeBuild가 실행하는 명령을 나타냅니다(있는 경우). 예를 들어, Amazon ECR에 로그인하기 위해 이 단계를 사용할 수 있습니다. 또는 npm 종속성을 설치할 수도 있습니다.    
phases/pre\$1build/**commands**  
`pre_build`를 지정한 경우 필수 시퀀스입니다. 스칼라 시퀀스를 포함합니다. 여기서 각 스칼라는 CodeBuild가 빌드 전에 실행하는 단일 명령을 나타냅니다. 빌드 단계마다, CodeBuild는 처음부터 끝까지 한 번에 하나씩 나열된 순서로 각 명령을 실행합니다.

phases/**build**  <a name="build-spec.phases.build"></a>
선택적 시퀀스. 빌드 중에 CodeBuild가 실행하는 명령을 나타냅니다(있는 경우). 예를 들어, Mocha, RSpec 또는 sbt를 실행하기 위해 이 단계를 사용할 수 있습니다.    
phases/build/**commands**  
`build`를 지정한 경우 필수입니다. 스칼라 시퀀스를 포함합니다. 여기서 각 스칼라는 CodeBuild가 빌드 중에 실행하는 단일 명령을 나타냅니다. 빌드 단계마다, CodeBuild는 처음부터 끝까지 한 번에 하나씩 나열된 순서로 각 명령을 실행합니다.

phases/**post\$1build**  <a name="build-spec.phases.post_build"></a>
선택적 시퀀스. 빌드 후에 CodeBuild가 실행하는 명령을 나타냅니다(있는 경우). 예를 들어, Maven을 사용하여 빌드 아티팩트를 JAR 또는 WAR 파일에 패키지할 수 있으며, Amazon ECR에 도커 이미지를 푸시할 수도 있습니다. 그런 다음, Amazon SNS를 통해 빌드 알림을 전송할 수도 있습니다.    
phases/post\$1build/**commands**  
`post_build`를 지정한 경우 필수입니다. 스칼라 시퀀스를 포함합니다. 여기서 각 스칼라는 CodeBuild가 빌드 후에 실행하는 단일 명령을 나타냅니다. 빌드 단계마다, CodeBuild는 처음부터 끝까지 한 번에 하나씩 나열된 순서로 각 명령을 실행합니다.<a name="reports-buildspec-file"></a>

### 보고서
<a name="build-spec.reports"></a>

**report-group-name-or-arn**  <a name="build-spec.reports.report-name-or-arn"></a>
선택적 시퀀스. 보고서를 전송할 보고서 그룹을 지정합니다. 프로젝트에는 최대 5개의 보고서 그룹이 포함될 수 있습니다. 기존 보고서 그룹의 ARN 또는 새 보고서 그룹의 이름을 지정합니다. 이름을 지정하는 경우 CodeBuild는 프로젝트 이름과 `<project-name>-<report-group-name>` 형식으로 지정한 이름을 사용하여 보고서 그룹을 생성합니다. 보고서 그룹 이름은 `$REPORT_GROUP_NAME`과 같은 빌드 사양의 환경 변수를 사용하여 설정할 수도 있습니다. 자세한 내용은 [보고서 그룹 이름 지정](test-report-group-naming.md) 단원을 참조하십시오.

reports/<report-group>/**files**  <a name="build-spec.reports.files"></a>
필수 시퀀스. 보고서에 의해 생성된 테스트 결과의 원시 데이터가 포함된 위치를 나타냅니다. 스칼라 시퀀스를 포함하며, 각 스칼라는 CodeBuild가 원래 빌드 위치와 관련하여 테스트 파일을 찾을 수 있는 별도의 위치 또는 설정된 경우 `base-directory`를 나타냅니다. 위치에는 다음이 포함될 수 있습니다.  
+ 단일 파일(예: `my-test-report-file.json`).
+ 하위 디렉터리의 단일 파일입니다(예: `my-subdirectory/my-test-report-file.json` 또는 `my-parent-subdirectory/my-subdirectory/my-test-report-file.json`).
+ `'**/*'`는 모든 파일을 재귀적으로 나타냅니다.
+ `my-subdirectory/*`는 *my-subdirectory*라는 하위 디렉터리에 있는 모든 파일을 나타냅니다.
+ `my-subdirectory/**/*`는 *my-subdirectory*라는 하위 디렉터리에서 시작하는 모든 파일을 재귀적으로 나타냅니다.

reports/<report-group>/**file-format**  <a name="build-spec.reports.file-format"></a>
선택적 매핑. 보고서 파일 형식을 나타냅니다. 지정하지 않으면 `JUNITXML`가 사용됩니다. 이 값은 대소문자를 구분하지 않습니다. 가능한 값은 다음과 같습니다.  
**테스트 보고서**    
 `CUCUMBERJSON`   
Cucumber JSON  
 `JUNITXML`   
JUnit XML  
 `NUNITXML`   
NUnit XML  
 `NUNIT3XML`   
NUnit 3 XML  
 `TESTNGXML`   
TestNG XML  
 `VISUALSTUDIOTRX`   
Visual Studio TRX
**코드 범위 보고서**    
 `CLOVERXML`   
Clover XML  
 `COBERTURAXML`   
Cobertura XML  
 `JACOCOXML`   
JacoCo XML  
 `SIMPLECOV`   
SimpleCov JSON  
CodeBuild는 [simplecov-json](https://github.com/vicentllongo/simplecov-json)이 아닌 [simplecov](https://github.com/simplecov-ruby/simplecov)에서 생성된 JSON 코드 범위 보고서를 수락합니다.

보고서/<report-group>/**기본 디렉터리**  <a name="build-spec.reports.base-directory"></a>
선택적 매핑. 원시 테스트 파일을 찾을 위치를 결정할 때 CodeBuild가 사용하는 원래 빌드 위치를 기준으로 하나 이상의 최상위 디렉터리를 나타냅니다.

reports/<report-group>/**discard-paths**  <a name="build-spec.reports.discard-paths"></a>
선택 사항. 보고서 파일 디렉터리가 출력에서 평면화되는지 여부를 지정합니다. 이 값이 지정되지 않거나 `no`를 포함하는 경우 보고서 파일은 디렉터리 구조가 손상되지 않은 상태로 출력됩니다. `yes`가 포함된 경우 모든 테스트 파일이 동일한 출력 디렉터리에 배치됩니다. 예를 들어, 테스트 결과에 대한 경로가 `com/myapp/mytests/TestResult.xml`인 경우 `yes`를 지정하면 이 파일이 `/TestResult.xml`에 배치됩니다.<a name="artifacts-build-spec"></a>

### artifacts
<a name="build-spec.artifacts"></a>

선택적 시퀀스. CodeBuild가 빌드 출력을 찾을 수 있는 위치 및 CodeBuild가 S3 출력 버킷에 업로드하기 위해 빌드 출력을 준비하는 방식에 대한 정보를 나타냅니다. 도커 이미지를 빌드하여 Amazon ECR에 푸시하는 경우 또는 소스 코드에 단위 테스트만 실행하고 빌드는 하지 않는 경우 등에는 이 시퀀스가 필요하지 않습니다.

**참고**  
Amazon S3 메타데이터에는 Amazon S3에 아티팩트를 게시하는 CodeBuild 빌드의 `buildArn`이 포함된 `x-amz-meta-codebuild-buildarn`라는 CodeBuild 헤더가 있습니다. 알림에 대한 소스 추적을 허용하고 아티팩트가 생성된 빌드를 참조할 수 있도록 하기 위해 `buildArn`이 추가되었습니다.

artifacts/**files**  <a name="build-spec.artifacts.files"></a>
필수 시퀀스. 빌드 환경의 빌드 출력 결과물을 포함하는 위치를 나타냅니다. 스칼라 시퀀스를 포함하며, 각 스칼라는 CodeBuild가 빌드 출력 결과물을 찾을 수 있는 개별 위치를 원래 빌드 위치 또는 기본 디렉터리(설정한 경우)를 기준으로 나타냅니다. 위치에는 다음이 포함될 수 있습니다.  
+ 단일 파일(예: `my-file.jar`).
+ 하위 디렉터리의 단일 파일입니다(예: `my-subdirectory/my-file.jar` 또는 `my-parent-subdirectory/my-subdirectory/my-file.jar`).
+ `'**/*'`는 모든 파일을 재귀적으로 나타냅니다.
+ `my-subdirectory/*`는 *my-subdirectory*라는 하위 디렉터리에 있는 모든 파일을 나타냅니다.
+ `my-subdirectory/**/*`는 *my-subdirectory*라는 하위 디렉터리에서 시작하는 모든 파일을 재귀적으로 나타냅니다.
빌드 출력 아티팩트 위치를 지정하면 CodeBuild가 빌드 환경의 원래 빌드 위치를 찾을 수 있습니다. 빌드 아티팩트 출력 위치 앞에 원래 빌드 위치 경로를 추가하거나 `./` 같은 것을 지정하지 않아도 됩니다. 이 위치에 대한 경로를 알고 싶으면 빌드 중에 `echo $CODEBUILD_SRC_DIR`과 같은 명령을 실행하면 됩니다. 각 빌드 환경의 위치는 약간씩 다를 수 있습니다.

artifacts/**name**  <a name="build-spec.artifacts.name"></a>
선택적 이름. 빌드 아티팩트의 이름을 지정합니다. 이 이름은 다음 중 하나에 해당될 때 사용됩니다.  
+ CodeBuild API를 사용하여 빌드를 생성하면 프로젝트가 업데이트되거나 생성되거나 빌드가 시작될 때 `ProjectArtifacts` 객체에 `overrideArtifactName` 플래그가 설정됩니다.
+ CodeBuild 콘솔을 사용하여 빌드를 생성하면 buildspec 파일에 이름이 지정되고, 프로젝트를 만들거나 업데이트할 때 **의미 체계 버전 관리 활성화**를 선택합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 단원을 참조하십시오.
빌드할 때 계산되는 buildspec 파일에서 이름을 지정할 수 있습니다. buildspec 파일에 지정된 이름은 Shell 명령 언어를 사용합니다. 예를 들어 아티팩트 이름이 항상 고유하도록 날짜와 시간을 아티팩트 이름에 추가할 수 있습니다. 고유한 결과물 이름을 사용하면 결과물을 덮어쓰지 않을 수 있습니다. 자세한 정보는 [Shell 명령 언어](http://pubs.opengroup.org/onlinepubs/9699919799/)를 참조하십시오.  
+ 다음은 아티팩트가 생성된 날짜가 추가된 아티팩트 이름의 예입니다 

  ```
  version: 0.2
  phases:
    build:
      commands:
        - rspec HelloWorld_spec.rb
  artifacts:
    files:
      - '**/*'
    name: myname-$(date +%Y-%m-%d)
  ```
+ 다음은 CodeBuild 환경 변수를 사용하는 아티팩트 이름의 예입니다. 자세한 내용은 [빌드 환경의 환경 변수](build-env-ref-env-vars.md) 단원을 참조하십시오.

  ```
  version: 0.2
  phases:
    build:
      commands:
        - rspec HelloWorld_spec.rb
  artifacts:
    files:
      - '**/*'
    name: myname-$AWS_REGION
  ```
+ 다음은 CodeBuild 환경 변수를 사용하여 아티팩트 생성 날짜가 추가된 아티팩트 이름의 예입니다.

  ```
  version: 0.2
  phases:
    build:
      commands:
        - rspec HelloWorld_spec.rb
  artifacts:
    files:
      - '**/*'
    name: $AWS_REGION-$(date +%Y-%m-%d)
  ```
이름에 경로 정보를 추가하여 이름의 경로를 기준으로 명명된 아티팩트가 디렉터리에 배치되도록 할 수 있습니다. 이 예제에서는 빌드 아티팩트가 출력의 `builds/<build number>/my-artifacts` 아래에 배치됩니다.  

```
version: 0.2
phases:
  build:
    commands:
      - rspec HelloWorld_spec.rb
artifacts:
  files:
    - '**/*'
  name: builds/$CODEBUILD_BUILD_NUMBER/my-artifacts
```

artifacts/**discard-paths**  <a name="build-spec.artifacts.discard-paths"></a>
선택 사항. 빌드 아티팩트 디렉터리가 출력에서 평면화되는지 여부를 지정합니다. 이 값이 지정되지 않거나 `no`를 포함하는 경우 빌드 아티팩트는 디렉터리 구조가 손상되지 않은 상태로 출력됩니다. `yes`가 포함된 경우 모든 빌드 아티팩트가 동일한 출력 디렉터리에 배치됩니다. 예를 들어, 빌드 출력 아티팩트의 파일 경로가 `com/mycompany/app/HelloWorld.java`인 경우 `yes`를 지정하면 이 파일이 `/HelloWorld.java`에 배치됩니다.

artifacts/**base-directory**  <a name="build-spec.artifacts.base-directory"></a>
선택적 매핑. CodeBuild가 빌드 출력 아티팩트에 포함할 파일 및 하위 디렉터리를 결정하는 데 사용하는 원래 빌드 위치에 상대적인 하나 이상의 최상위 디렉터리를 나타냅니다. 유효한 값으로는 다음이 포함됩니다.  
+ 단일 최상위 디렉터리입니다(예: `my-directory`).
+ `'my-directory*'`는 이름이 `my-directory`로 시작하는 모든 최상위 디렉터리를 나타냅니다.
빌드 출력 결과물에는 이 최상위 디렉터리가 포함되지 않으며, 파일 및 하위 디렉터리만 포함됩니다.  
포함할 파일 및 하위 디렉터리를 보다 더 제한하려면 `files` 및 `discard-paths`를 사용하면 됩니다. 예를 들어 다음 디렉터리구조에서   

```
.
├── my-build-1
│   └── my-file-1.txt
└── my-build-2
    ├── my-file-2.txt
    └── my-subdirectory
        └── my-file-3.txt
```
다음 `artifacts` 시퀀스에 대해:  

```
artifacts:
  files:
    - '*/my-file-3.txt'
  base-directory: my-build-2
```
다음 하위 디렉터리 및 파일이 빌드 출력 결과물에 포함됩니다.  

```
.
└── my-subdirectory
    └── my-file-3.txt
```
다음 `artifacts` 시퀀스 동안  

```
artifacts:
  files:
    - '**/*'
  base-directory: 'my-build*'
  discard-paths: yes
```
다음 파일이 빌드 출력 결과물에 포함됩니다.  

```
.
├── my-file-1.txt
├── my-file-2.txt
└── my-file-3.txt
```

artifacts/**exclude-paths**  <a name="build-spec.artifacts.exclude-paths"></a>
선택적 매핑. CodeBuild가 빌드 아티팩트에서 제외할 `base-directory`에 상대적인 하나 이상의 경로를 나타냅니다. 별표(`*`) 문자는 폴더의 경계를 넘지 않고 0개 이상의 이름 구성 요소 문자와 해당합니다. 이중 별표(`**`)는 모든 디렉터리에서 이름 구성 요소의 0개 이상 문자와 일치합니다.  
exclude-paths의 예는 다음과 같습니다.  
+ 모든 디렉터리에서 파일을 제외하려면: `"**/file-name/**/*"`
+ 모든 dot 폴더를 제외하려면: `"**/.*/**/*"`
+ 모든 dot 파일을 제외하려면: `"**/.*"`

artifacts/**enable-symlinks**  <a name="build-spec.artifacts.enable-symlinks"></a>
선택 사항. 출력 유형이 `ZIP`인 경우 내부 심볼 링크를 ZIP 파일에 보존할지 여부를 지정합니다. 이 파일에 `yes`가 포함된 경우 소스의 모든 내부 심볼 링크가 아티팩트 ZIP 파일에 보존됩니다.

artifacts/**s3-prefix**  <a name="build-spec.artifacts.s3-prefix"></a>
선택 사항. 아티팩트가 Amazon S3 버킷으로 출력되고 네임스페이스 유형이 `BUILD_ID`일 때 사용되는 접두사를 지정합니다. 사용될 경우 버킷의 출력 경로는 `<s3-prefix>/<build-id>/<name>.zip`입니다.

artifacts/**secondary-artifacts**  <a name="build-spec.artifacts.secondary-artifacts"></a>
선택적 시퀀스. 1개 이상의 아티팩트 정의를 아티팩트 식별자와 아티팩트 정의를 연결하는 매핑으로 나타냅니다. 이 블록에서는 각 아티팩트가 프로젝트의 `secondaryArtifacts` 속성에서 정의하는 아티팩트와 일치해야 합니다. 각 정의는 위의 `artifacts` 블록과 동일한 구문을 갖습니다.  
2차 아티팩트만 정의된 경우에도 [`artifacts/files`](#build-spec.artifacts.files) 시퀀스는 항상 필요합니다.
예를 들어 프로젝트가 다음과 같은 구조라고 가정할 경우,  

```
{
  "name": "sample-project",
  "secondaryArtifacts": [
    {
      "type": "S3",
      "location": "<output-bucket1>",
      "artifactIdentifier": "artifact1",
      "name": "secondary-artifact-name-1"
    },
    {
      "type": "S3",
      "location": "<output-bucket2>",
      "artifactIdentifier": "artifact2",
      "name": "secondary-artifact-name-2"
    }
  ]
}
```
buildpec 파일은 다음과 비슷합니다.  

```
version: 0.2

phases:
build:
  commands:
    - echo Building...
artifacts:
  files:
    - '**/*'
  secondary-artifacts:
    artifact1:
      files:
        - directory/file1
      name: secondary-artifact-name-1
    artifact2:
      files:
        - directory/file2
      name: secondary-artifact-name-2
```

### cache
<a name="build-spec.cache"></a>

선택적 시퀀스. CodeBuild가 S3 캐시 버킷에 캐시를 업로드하기 위해 준비할 수 있는 파일에 대한 정보를 나타냅니다. 프로젝트의 캐시 유형이 `No Cache`인 경우 이 시퀀스는 필수가 아닙니다.

캐시/**키**  <a name="build-spec.cache.key"></a>
선택적 시퀀스. 캐시를 검색하거나 복원할 때 사용되는 기본 키를 나타냅니다. CodeBuild는 기본 키와 정확히 일치합니다.  
다음은 키의 예입니다.  

```
key: npm-key-$(codebuild-hash-files package-lock.json) }
```

캐시/**폴백 키**  <a name="build-spec.cache.fallback-keys"></a>
선택적 시퀀스. 프라이머리 키를 사용하여 캐시를 찾을 수 없을 때 순차적으로 사용되는 대체 키 목록을 나타냅니다. 최대 5개의 폴백 키가 지원되며 각 폴백 키는 접두사 검색을 사용하여 일치됩니다. **키**가 제공되지 않으면 이 시퀀스는 무시됩니다.  
다음은 폴백 키의 예입니다.  

```
fallback-keys:
    - npm-key-$(codebuild-hash-files package-lock.json) }
    - npm-key-
    - npm-
```

캐시/**작업**  <a name="build-spec.cache.action"></a>
선택적 시퀀스. 캐시에서 수행할 작업을 지정합니다. 유효한 값으로는 다음이 포함됩니다.  
+ `restore`는 업데이트를 저장하지 않고 캐시만 복원합니다.
+ `save`는 이전 버전을 복원하지 않고 캐시만 저장합니다.
값이 제공되지 않으면 CodeBuild는 기본적으로 복원과 저장을 모두 수행합니다.

cache/**paths**  <a name="build-spec.cache.paths"></a>
필수 시퀀스. 캐시의 위치를 나타냅니다. 스칼라 시퀀스를 포함하며, 각 스칼라는 CodeBuild가 빌드 출력 결과물을 찾을 수 있는 개별 위치를 원래 빌드 위치 또는 기본 디렉터리(설정한 경우)를 기준으로 나타냅니다. 위치에는 다음이 포함될 수 있습니다.  
+ 단일 파일(예: `my-file.jar`).
+ 하위 디렉터리의 단일 파일입니다(예: `my-subdirectory/my-file.jar` 또는 `my-parent-subdirectory/my-subdirectory/my-file.jar`).
+ `'**/*'`는 모든 파일을 재귀적으로 나타냅니다.
+ `my-subdirectory/*`는 *my-subdirectory*라는 하위 디렉터리에 있는 모든 파일을 나타냅니다.
+ `my-subdirectory/**/*`는 *my-subdirectory*라는 하위 디렉터리에서 시작하는 모든 파일을 재귀적으로 나타냅니다.

**중요**  
buildspec 선언은 올바른 YAML이어야 하므로 buildspec 선언의 공백 설정이 중요합니다. buildspec 선언의 공백 수가 잘못되면 빌드가 즉시 실패할 수 있습니다. YAML 유효성 검사기를 사용하여 buildspec 선언이 올바른 YAML인지 여부를 테스트할 수 있습니다.  
빌드 프로젝트를 생성 AWS CLI하거나 업데이트할 때 또는 AWS SDKs를 사용하여 buildspec을 선언하는 경우 buildspec은 필수 공백 및 줄 바꿈 이스케이프 문자와 함께 YAML 형식으로 표현된 단일 문자열이어야 합니다. 다음 섹션에 예가 나와 있습니다.  
buildspec.yml 파일 대신 CodeBuild 또는 AWS CodePipeline 콘솔을 사용하는 경우 `build` 단계에 대해서만 명령을 삽입할 수 있습니다. 앞에 나온 구문을 사용하는 대신, 빌드 단계 중에 실행하려는 모든 명령을 하나의 행에 나열합니다. 명령이 여러 개인 경우 각 명령을 `&&`로 구분합니다(예: `mvn test && mvn package`).  
buildspec.yml 파일 대신 CodeBuild 또는 CodePipeline 콘솔을 사용하여 빌드 환경의 빌드 출력 아티팩트 위치를 지정할 수 있습니다. 앞에 나온 구문을 사용하는 대신, 모든 위치를 하나의 행에 나열합니다. 위치가 여러 개인 경우 각 위치를 쉼표로 구분합니다(예: `buildspec.yml, target/my-app.jar`).

## buildspec 예제
<a name="build-spec-ref-example"></a>

다음은 buildspec.yml 파일의 예입니다.

```
version: 0.2

env:
  variables:
    JAVA_HOME: "/usr/lib/jvm/java-8-openjdk-amd64"
  parameter-store:
    LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword

phases:
  install:
    commands:
      - echo Entered the install phase...
      - apt-get update -y
      - apt-get install -y maven
    finally:
      - echo This always runs even if the update or install command fails 
  pre_build:
    commands:
      - echo Entered the pre_build phase...
      - docker login -u User -p $LOGIN_PASSWORD
    finally:
      - echo This always runs even if the login command fails 
  build:
    commands:
      - echo Entered the build phase...
      - echo Build started on `date`
      - mvn install
    finally:
      - echo This always runs even if the install command fails
  post_build:
    commands:
      - echo Entered the post_build phase...
      - echo Build completed on `date`

reports:
  arn:aws:codebuild:your-region:your-aws-account-id:report-group/report-group-name-1:
    files:
      - "**/*"
    base-directory: 'target/tests/reports'
    discard-paths: no
  reportGroupCucumberJson:
    files:
      - 'cucumber/target/cucumber-tests.xml'
    discard-paths: yes
    file-format: CUCUMBERJSON # default is JUNITXML
artifacts:
  files:
    - target/messageUtil-1.0.jar
  discard-paths: yes
  secondary-artifacts:
    artifact1:
      files:
        - target/artifact-1.0.jar
      discard-paths: yes
    artifact2:
      files:
        - target/artifact-2.0.jar
      discard-paths: yes
cache:
  paths:
    - '/root/.m2/**/*'
```

다음은 AWS CLI또는 AWS SDKs.

```
"version: 0.2\n\nenv:\n  variables:\n    JAVA_HOME: \"/usr/lib/jvm/java-8-openjdk-amd64\\"\n  parameter-store:\n    LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword\n  phases:\n\n  install:\n    commands:\n      - echo Entered the install phase...\n      - apt-get update -y\n      - apt-get install -y maven\n    finally:\n      - echo This always runs even if the update or install command fails \n  pre_build:\n    commands:\n      - echo Entered the pre_build phase...\n      - docker login -u User -p $LOGIN_PASSWORD\n    finally:\n      - echo This always runs even if the login command fails \n  build:\n    commands:\n      - echo Entered the build phase...\n      - echo Build started on `date`\n      - mvn install\n    finally:\n      - echo This always runs even if the install command fails\n  post_build:\n    commands:\n      - echo Entered the post_build phase...\n      - echo Build completed on `date`\n\n reports:\n  reportGroupJunitXml:\n    files:\n      - \"**/*\"\n    base-directory: 'target/tests/reports'\n    discard-paths: false\n  reportGroupCucumberJson:\n    files:\n      - 'cucumber/target/cucumber-tests.xml'\n    file-format: CUCUMBERJSON\n\nartifacts:\n  files:\n    - target/messageUtil-1.0.jar\n  discard-paths: yes\n  secondary-artifacts:\n    artifact1:\n      files:\n       - target/messageUtil-1.0.jar\n      discard-paths: yes\n    artifact2:\n      files:\n       - target/messageUtil-1.0.jar\n      discard-paths: yes\n cache:\n  paths:\n    - '/root/.m2/**/*'"
```

다음은 CodeBuild 또는 CodePipeline 콘솔과 함께 사용하기 위한 `build` 단계의 명령 예입니다.

```
echo Build started on `date` && mvn install
```

아래 예에서
+ `JAVA_HOME`의 키 및 `/usr/lib/jvm/java-8-openjdk-amd64`의 값이 있는 일반 텍스트의 사용자 지정 환경 변수가 설정됩니다.
+ Amazon EC2 Systems Manager Parameter Store에 저장된 `dockerLoginPassword`라는 사용자 지정 환경 변수는 나중에 `LOGIN_PASSWORD` 키를 사용하여 빌드 명령에서 참조됩니다.
+ 이러한 빌드 단계 이름은 변경할 수 없습니다. 이 예에서 실행될 명령은 `apt-get update -y` 및 `apt-get install -y maven`(Apache Maven을 설치하는 데 사용), `mvn install`(소스 코드를 빌드 출력 아티팩트로 컴파일, 테스트 및 패키징하고 빌드 출력 아티팩트를 내부 리포지토리에 설치하는 데 사용), `docker login`(Amazon EC2 Systems Manager Parameter Store에 설정한 사용자 지정 환경 변수 `dockerLoginPassword`의 값에 해당하는 암호로 Docker에 로그인하는 데 사용) 및 여러 `echo` 명령입니다. `echo` 명령은 CodeBuild가 명령을 실행하는 방식 및 명령 실행 순서를 보여 주기 위해 포함된 것입니다.
+ `files`는 빌드 출력 위치에 업로드할 파일을 나타냅니다. 이 예에서 CodeBuild는 단일 파일 `messageUtil-1.0.jar`을 업로드합니다. `messageUtil-1.0.jar` 파일은 빌드 환경의 `target`이라는 상대적 디렉터리에서 찾을 수 있습니다. `discard-paths: yes`가 지정되어 있으므로, `messageUtil-1.0.jar`가 바로 업로드됩니다(중간의 `target` 디렉터리를 거치지 않음). 파일 이름 `messageUtil-1.0.jar` 및 상대적 디렉터리 이름 `target`은 Apache Maven이 이 예제에서만 빌드 출력 결과물을 생성 및 저장하는 방식에 따라 달라집니다. 사용자 자체 시나리오에서는 이러한 파일 이름과 디렉터리가 다릅니다.
+ `reports`는 빌드 중에 보고서를 생성하는 두 개의 보고서 그룹을 나타냅니다.
  + `arn:aws:codebuild:your-region:your-aws-account-id:report-group/report-group-name-1`는 보고서 그룹의 ARN을 지정합니다. 테스트 프레임워크에 의해 생성된 테스트 결과는 `target/tests/reports` 디렉터리에 있습니다. 파일 형식은 `JunitXml`이고 테스트 결과가 포함된 파일에서 경로가 제거되지 않습니다.
  + `reportGroupCucumberJson`는 새 보고서 그룹을 지정합니다. 프로젝트 이름이 `my-project`인 경우 빌드가 실행될 때 이름이 `my-project-reportGroupCucumberJson`인 보고서 그룹이 생성됩니다. 테스트 프레임워크에 의해 생성된 테스트 결과가 `cucumber/target/cucumber-tests.xml`에 있습니다. 테스트 파일 형식은 `CucumberJson`이고 테스트 결과가 포함된 파일에서 경로가 제거됩니다.

## buildspec 버전
<a name="build-spec-ref-versions"></a>

다음 표에는 buildspec 버전과 버전 간의 변경 사항이 나열되어 있습니다.


| 버전 | 변경 사항 | 
| --- | --- | 
| 0.2 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/build-spec-ref.html)  | 
| 0.1 | 이는 빌드 사양 형식의 초기 정의입니다. | 

# 배치 빌드 buildspec 참조
<a name="batch-build-buildspec"></a>

이 주제에는 배치 빌드 속성에 대한 buildspec 참조가 포함되어 있습니다.

## 일괄
<a name="build-spec.batch"></a>

선택적 매핑. 프로젝트에 대한 배치 빌드 설정입니다.

배치/**빠른 실패**  
선택 사항입니다. 하나 이상의 빌드 태스크가 실패할 경우 배치 빌드의 동작을 지정합니다.    
`false`  
기본값입니다. 실행 중인 모든 빌드가 완료됩니다.  
`true`  
빌드 태스크 중 하나가 실패하면 실행 중인 모든 빌드가 중지됩니다.

기본적으로 모든 배치 빌드 태스크는 buildspec 파일에 지정된 `env` 및 `phases`와 같은 빌드 설정으로 실행됩니다. `batch/<batch-type>/buildspec` 파라미터에 다른 `env` 값이나 다른 buildspec 파일을 지정하여 기본 빌드 설정을 재정의할 수 있습니다.

`batch` 속성의 내용은 지정된 배치 빌드 유형에 따라 달라집니다. 가능한 배치 빌드 유형은 다음과 같습니다.
+ [`batch/build-graph`](#build-spec.batch.build-graph)
+ [`batch/build-list`](#build-spec.batch.build-list)
+ [`batch/build-matrix`](#build-spec.batch.build-matrix)
+ [`batch/build-fanout`](#build-spec.batch.build-fanout)

## `batch/build-graph`
<a name="build-spec.batch.build-graph"></a>

*빌드 그래프*를 정의합니다. 빌드 그래프는 일괄 처리의 다른 태스크에 종속되는 일련의 태스크를 정의합니다. 자세한 내용은 [빌드 그래프](batch-build.md#batch_build_graph) 섹션을 참조하세요.

이 요소에는 빌드 태스크의 배열이 포함되어 있습니다. 각 빌드 태스크는 다음 속성을 포함합니다.

**identifier**  
필수 사항입니다. 태스크의 식별자입니다.

**buildspec**  
선택 사항입니다. 태스크에 사용할 buildspec 파일의 경로 및 파일 이름입니다. 이 파라미터를 지정하지 않으면 현재 buildspec인 파일이 사용됩니다.

**debug-session**  
선택 사항입니다. 이 배치 빌드에 세션 디버깅을 활성화할지를 여부를 나타내는 부울 값입니다. 세션 디버깅에 대한 자세한 내용은 [Session Manager를 사용하여 빌드 디버그](session-manager.md) 섹션을 참조하세요.    
`false`  
세션 디버깅이 비활성화되었습니다.  
`true`  
세션 디버깅이 활성화되었습니다.

**depend-on**  
선택 사항입니다. 이 태스크가 의존하는 태스크 식별자의 배열입니다. 이 태스크는 이러한 태스크가 완료될 때까지 실행되지 않습니다.

**env**  
선택 사항입니다. 태스크에 대한 빌드 환경 재정의입니다. 여기에는 다음 속성이 포함됩니다.    
**compute-type**  
태스크에 사용할 컴퓨팅 유형의 식별자입니다. 가능한 값은 [빌드 환경 컴퓨팅 모드 및 유형](build-env-ref-compute-types.md)의 **computeType**을 참조하세요.  
** 플릿**  
작업에 사용할 플릿의 식별자입니다. 자세한 정보는 [예약 용량 플릿에서 빌드 실행](fleets.md)을 참조하세요.  
**image**  
태스크에 사용할 이미지의 식별자입니다. 가능한 값은 [CodeBuild가 제공하는 도커 이미지](build-env-ref-available.md)의 **이미지 식별자**를 참조하세요.  
**privileged-mode**  
Docker 컨테이너 내부에서 Docker 데몬(daemon)을 실행할지 여부를 나타내는 부울 값입니다. 빌드 프로젝트가 도커 이미지를 빌드하는 데 사용되는 경우에만 `true`로 설정합니다. 그렇지 않으면 도커 데몬과 상호 작용을 시도하는 빌드가 실패합니다. 기본 설정은 `false`입니다.  
**type**  
태스크에 사용할 환경 유형의 식별자입니다. 가능한 값은 [빌드 환경 컴퓨팅 모드 및 유형](build-env-ref-compute-types.md)에서 **환경 유형**을 참조하세요.  
**variables**  
빌드 환경에 표시될 환경 변수입니다. 자세한 내용은 [env/variables](build-spec-ref.md#build-spec.env.variables) 섹션을 참조하세요.
단일 빌드의 동일한 식별자에는 **컴퓨팅 유형**과 **플릿**을 제공할 수 없습니다.

**ignore-failure**  
선택 사항입니다. 이 빌드 태스크의 실패를 무시할 수 있는지 여부를 나타내는 부울 값입니다.    
`false`  
기본값입니다. 이 빌드 태스크가 실패하면 배치 빌드가 실패합니다.  
`true`  
이 빌드 태스크가 실패하더라도 배치 빌드는 여전히 성공할 수 있습니다.

다음은 빌드 그래프 buildSpec 항목의 예제입니다.

```
batch:
  fast-fail: false
  build-graph:
    - identifier: build1
      env:
        variables:
          BUILD_ID: build1
      ignore-failure: false
    - identifier: build2
      buildspec: build2.yml
      env:
        variables:
          BUILD_ID: build2
      depend-on:
        - build1
    - identifier: build3
      env:
        variables:
          BUILD_ID: build3
      depend-on:
        - build2
    - identifier: build4
      env:
        compute-type: ARM_LAMBDA_1GB
    - identifier: build5
      env:
        fleet: fleet_name
```

## `batch/build-list`
<a name="build-spec.batch.build-list"></a>

*빌드 목록*을 정의합니다. 빌드 목록은 병렬로 실행되는 여러 태스크를 정의하는 데 사용됩니다. 자세한 내용은 [빌드 목록](batch-build.md#batch_build_list) 섹션을 참조하세요.

이 요소에는 빌드 태스크의 배열이 포함되어 있습니다. 각 빌드 태스크는 다음 속성을 포함합니다.

**identifier**  
필수 사항입니다. 태스크의 식별자입니다.

**buildspec**  
선택 사항입니다. 태스크에 사용할 buildspec 파일의 경로 및 파일 이름입니다. 이 파라미터를 지정하지 않으면 현재 buildspec인 파일이 사용됩니다.

**debug-session**  
선택 사항입니다. 이 배치 빌드에 세션 디버깅을 활성화할지를 여부를 나타내는 부울 값입니다. 세션 디버깅에 대한 자세한 내용은 [Session Manager를 사용하여 빌드 디버그](session-manager.md) 섹션을 참조하세요.    
`false`  
세션 디버깅이 비활성화되었습니다.  
`true`  
세션 디버깅이 활성화되었습니다.

**env**  
선택 사항입니다. 태스크에 대한 빌드 환경 재정의입니다. 여기에는 다음 속성이 포함됩니다.    
**compute-type**  
태스크에 사용할 컴퓨팅 유형의 식별자입니다. 가능한 값은 [빌드 환경 컴퓨팅 모드 및 유형](build-env-ref-compute-types.md)의 **computeType**을 참조하세요.  
** 플릿**  
작업에 사용할 플릿의 식별자입니다. 자세한 정보는 [예약 용량 플릿에서 빌드 실행](fleets.md)을 참조하세요.  
**image**  
태스크에 사용할 이미지의 식별자입니다. 가능한 값은 [CodeBuild가 제공하는 도커 이미지](build-env-ref-available.md)의 **이미지 식별자**를 참조하세요.  
**privileged-mode**  
Docker 컨테이너 내부에서 Docker 데몬(daemon)을 실행할지 여부를 나타내는 부울 값입니다. 빌드 프로젝트가 도커 이미지를 빌드하는 데 사용되는 경우에만 `true`로 설정합니다. 그렇지 않으면 도커 데몬과 상호 작용을 시도하는 빌드가 실패합니다. 기본 설정은 `false`입니다.  
**type**  
태스크에 사용할 환경 유형의 식별자입니다. 가능한 값은 [빌드 환경 컴퓨팅 모드 및 유형](build-env-ref-compute-types.md)에서 **환경 유형**을 참조하세요.  
**variables**  
빌드 환경에 표시될 환경 변수입니다. 자세한 내용은 [env/variables](build-spec-ref.md#build-spec.env.variables) 섹션을 참조하세요.
단일 빌드의 동일한 식별자에는 **컴퓨팅 유형**과 **플릿**을 제공할 수 없습니다.

**ignore-failure**  
선택 사항입니다. 이 빌드 태스크의 실패를 무시할 수 있는지 여부를 나타내는 부울 값입니다.    
`false`  
기본값입니다. 이 빌드 태스크가 실패하면 배치 빌드가 실패합니다.  
`true`  
이 빌드 태스크가 실패하더라도 배치 빌드는 여전히 성공할 수 있습니다.

다음은 빌드 목록 buildSpec 항목의 예제입니다.

```
batch:
  fast-fail: false
  build-list:
    - identifier: build1
      env:
        variables:
          BUILD_ID: build1
      ignore-failure: false
    - identifier: build2
      buildspec: build2.yml
      env:
        variables:
          BUILD_ID: build2
      ignore-failure: true
    - identifier: build3
      env:
        compute-type: ARM_LAMBDA_1GB
    - identifier: build4
      env:
        fleet: fleet_name
    - identifier: build5
      env:
        compute-type: GENERAL_LINUX_XLAGRE
```

## `batch/build-matrix`
<a name="build-spec.batch.build-matrix"></a>

*빌드 매트릭스*를 정의합니다. 빌드 매트릭스는 병렬로 실행되는 다양한 구성의 태스크를 정의합니다. CodeBuild는 가능한 각 구성 조합에 대해 별도의 빌드를 생성합니다. 자세한 내용은 [빌드 매트릭스](batch-build.md#batch_build_matrix) 섹션을 참조하세요.

**static**  
정적 속성은 모든 빌드 태스크에 적용됩니다.    
**ignore-failure**  
선택 사항입니다. 이 빌드 태스크의 실패를 무시할 수 있는지 여부를 나타내는 부울 값입니다.    
`false`  
기본값입니다. 이 빌드 태스크가 실패하면 배치 빌드가 실패합니다.  
`true`  
이 빌드 태스크가 실패하더라도 배치 빌드는 여전히 성공할 수 있습니다.  
**env**  
선택 사항입니다. 모든 태스크에 대한 빌드 환경 재정의입니다.    
**privileged-mode**  
Docker 컨테이너 내부에서 Docker 데몬(daemon)을 실행할지 여부를 나타내는 부울 값입니다. 빌드 프로젝트가 도커 이미지를 빌드하는 데 사용되는 경우에만 `true`로 설정합니다. 그렇지 않으면 도커 데몬과 상호 작용을 시도하는 빌드가 실패합니다. 기본 설정은 `false`입니다.  
**type**  
태스크에 사용할 환경 유형의 식별자입니다. 가능한 값은 [빌드 환경 컴퓨팅 모드 및 유형](build-env-ref-compute-types.md)에서 **환경 유형**을 참조하세요.

**dynamic**  
동적 속성은 빌드 매트릭스를 정의합니다.    
**buildspec**  
선택 사항입니다. 이러한 태스크에 사용할 buildspec 파일의 경로와 파일 이름을 포함하는 배열입니다. 이 파라미터를 지정하지 않으면 현재 buildspec인 파일이 사용됩니다.  
**env**  
선택 사항입니다. 이러한 태스크에 대해 빌드 환경이 재정의됩니다.    
**compute-type**  
이러한 태스크에 사용할 컴퓨팅 유형의 식별자가 포함된 배열입니다. 가능한 값은 [빌드 환경 컴퓨팅 모드 및 유형](build-env-ref-compute-types.md)의 **computeType**을 참조하세요.  
**image**  
이러한 태스크에 사용할 이미지의 식별자가 포함된 배열입니다. 가능한 값은 [CodeBuild가 제공하는 도커 이미지](build-env-ref-available.md)의 **이미지 식별자**를 참조하세요.  
**variables**  
이러한 태스크에 대한 빌드 환경에 표시될 환경 변수를 포함하는 배열입니다. 자세한 내용은 [env/variables](build-spec-ref.md#build-spec.env.variables) 섹션을 참조하세요.

다음은 빌드 매트릭스 buildSpec 항목의 예제입니다.

```
batch:
  build-matrix:
    static:
      ignore-failure: false
    dynamic:
      buildspec: 
        - matrix1.yml
        - matrix2.yml
      env:
        variables:
          MY_VAR:
            - VALUE1
            - VALUE2
            - VALUE3
```

자세한 내용은 [빌드 매트릭스](batch-build.md#batch_build_matrix) 섹션을 참조하세요.

## `batch/build-fanout`
<a name="build-spec.batch.build-fanout"></a>

*빌드 팬아웃*을 정의합니다. 빌드 팬아웃은 병렬로 실행되는 여러 빌드로 분할되는 작업을 정의하는 데 사용됩니다. 자세한 내용은 [배치 빌드에서 병렬 테스트 실행](parallel-test.md) 섹션을 참조하세요.

이 요소에는 여러 빌드로 분할할 수 있는 빌드 작업이 포함되어 있습니다. `build-fanout` 섹션은 다음 속성을 포함하고 있습니다.

**parallelism**  
필수 사항입니다. 병렬로 테스트를 실행할 빌드 수입니다.

**ignore-failure**  
선택 사항입니다. 팬아웃 빌드 작업에서 실패를 무시할 수 있는지를 나타내는 부울 값입니다. 이 값인 **ignore-failure**는 모든 팬아웃 빌드에 적용됩니다.    
**'`false**`'  
기본값입니다. 팬아웃 빌드 작업이 실패하면 배치 빌드가 실패합니다.  
**'`true**`'  
팬아웃 빌드 작업이 실패하더라도 배치 빌드는 여전히 성공할 수 있습니다.

다음은 빌드 팬아웃 buildspec 항목의 예제입니다.

```
version: 0.2

batch:
   fast-fail: false 
   build-fanout:
     parallelism: 5
     ignore-failure: false

phases:
  install:
    commands:
      - npm install
   build:
    commands:
      - mkdir -p test-results
      - cd test-results
      - |
        codebuild-tests-run \
         --test-command 'npx jest --runInBand --coverage' \
         --files-search "codebuild-glob-search '**/test/**/*.test.js'" \
         --sharding-strategy 'equal-distribution'
```

자세한 내용은 [빌드 팬아웃](batch-build.md#batch_build_fanout) 및 [`codebuild-tests-run` CLI 명령 사용](parallel-test-tests-run.md)(을)를 참조하세요.