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

# 빌드 프로젝트
<a name="working-with-build-projects"></a>

이 빌드 프로젝트에는 소스 코드를 가져올 위치, 사용할 빌드 환경, 실행할 빌드 명령 및 빌드 출력을 저장할 위치를 비롯하여 빌드 실행 방법에 대한 정보가 포함되어 있습니다.**

빌드 프로젝트 작업을 수행할 때 이러한 태스크를 수행할 수 있습니다.

**Topics**
+ [에서 빌드 프로젝트 생성AWS CodeBuild](create-project.md)
+ [알림 규칙 생성](notification-rule-create.md)
+ [에서 빌드 프로젝트 설정 변경 AWS CodeBuild](change-project.md)
+ [CodeBuild의 다중 액세스 토큰](multiple-access-tokens.md)
+ [AWS CodeBuild에서 빌드 프로젝트 삭제](delete-project.md)
+ [퍼블릭 빌드 프로젝트 URL 가져오기](public-builds.md)
+ [빌드 프로젝트 공유](project-sharing.md)
+ [빌드 프로젝트 태그 지정](how-to-tag-project.md)
+ [에서 실행기 사용 AWS CodeBuild](runners.md)
+ [에서 웹후크 사용 AWS CodeBuild](webhooks.md)
+ [에서 빌드 프로젝트의 세부 정보 보기 AWS CodeBuild](view-project-details.md)
+ [에서 빌드 프로젝트 이름 보기 AWS CodeBuild](view-project-list.md)

# 에서 빌드 프로젝트 생성AWS CodeBuild
<a name="create-project"></a>

AWS CodeBuild 콘솔, AWS CLI 또는 AWS SDK를 사용하여 빌드 프로젝트를 생성할 수 있습니다.

**Topics**
+ [사전 조건](#create-project-prerequisites)
+ [빌드 프로젝트 만들기(콘솔)](#create-project-console)
+ [빌드 프로젝트 생성(AWS CLI)](#create-project-cli)
+ [빌드 프로젝트 생성(AWS SDK)](#create-project-sdks)
+ [빌드 프로젝트 생성(CloudFormation)](#create-project-cloud-formation)

## 사전 조건
<a name="create-project-prerequisites"></a>

빌드 프로젝트를 생성하기 전에 [빌드 계획](planning.md)의 질문에 답변하세요.

## 빌드 프로젝트 만들기(콘솔)
<a name="create-project-console"></a>

[https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)에서 AWS CodeBuild 콘솔을 엽니다.

 CodeBuild 정보 페이지가 나타나면 **빌드 프로젝트 생성**을 선택합니다. 그렇지 않을 경우, 탐색 창에서 **빌드**를 확장한 후 **빌드 프로젝트**를 선택하고 **빌드 프로젝트 생성**을 선택합니다.

**빌드 프로젝트 생성**을 선택합니다.

다음 섹션을 채웁니다. 완료되면 페이지 하단에서 **빌드 프로젝트 생성**을 선택합니다.

**Topics**
+ [프로젝트 구성](#create-project-console-project-config)
+ [소스](#create-project-console-source)
+ [환경](#create-project-console-environment)
+ [Buildspec](#create-project-console-buildspec)
+ [배치 구성](#create-project-console-batch-config)
+ [Artifacts](#create-project-console-artifacts)
+ [로그](#create-project-console-logs)

### 프로젝트 구성
<a name="create-project-console-project-config"></a>

**프로젝트 이름**:   
이 빌드 프로젝트의 이름을 입력합니다. 각 AWS 계정에서 빌드 프로젝트 이름은 고유해야 합니다.

**설명**  
선택적으로 빌드 프로젝트에 대한 설명을 입력하여 다른 사용자가 이 프로젝트의 용도를 이해하도록 도울 수 있습니다.

**빌드 배지**  
(선택 사항) 프로젝트의 빌드 상태를 표시하고 삽입 가능하게 하려면 **빌드 배치 활성화**를 선택합니다. 자세한 내용은 [빌드 배지 샘플](sample-build-badges.md) 섹션을 참조하세요.  
소스 공급자가 Amazon S3인 경우 빌드 배지가 적용되지 않습니다.

**동시 빌드 제한 활성화**  <a name="enable-concurrent-build-limit.console"></a>
(선택 사항) 이 프로젝트의 동시 빌드 수를 제한하려면 다음 단계를 수행합니다.  

1. **이 프로젝트에서 시작할 수 있는 동시 빌드 수 제한**을 선택합니다.

1. **동시 빌드 제한**에 이 프로젝트에 허용되는 최대 동시 빌드 수를 입력합니다. 이 제한은 계정에 설정된 동시 빌드 제한보다 클 수 없습니다. 계정 제한보다 큰 숫자를 입력하려고 하면 오류 메시지가 표시됩니다.
현재 빌드 수가 이 한도 이하인 경우에만 새 빌드가 시작됩니다. 현재 빌드 수가 이 한도에 도달하면 새 빌드가 제한되고 실행되지 않습니다.

**추가 정보**:  
(선택 사항) **태그**의 경우 지원되는 AWS 서비스에서 사용할 태그의 이름과 값을 입력합니다. [**Add row**]를 사용하여 태그를 추가합니다. 최대 50개의 태그를 추가할 수 있습니다.

### 소스
<a name="create-project-console-source"></a>

**소스 공급자**  
소스 코드 공급자 유형을 선택합니다. 다음 목록을 사용하여 소스 공급자에 알맞은 유형을 선택합니다.  
CodeBuild에서는 Bitbucket Server를 지원하지 않습니다.

------
#### [ Amazon S3 ]

 ** 버킷**   
소스 코드가 포함된 입력 버킷의 이름을 선택합니다.

 **S3 객체 키 또는 S3 폴더**   
소스 코드가 포함된 ZIP 파일의 이름 또는 폴더 경로를 입력합니다. S3 버킷의 모든 항목을 다운로드하려면 슬래시(/)를 입력합니다.

 **소스 버전**   
입력 파일의 빌드를 나타내는 객체의 버전 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md)을 참조하세요.

------
#### [ CodeCommit ]

 **리포지토리**   
사용할 리포지토리를 선택합니다.

**참조 유형**  
**분기**, **Git 태그** 또는 **커밋 ID**를 선택하여 소스 코드 버전을 지정합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
이력이 지정된 커밋 수로 잘린 부분 복제를 생성하려면 선택합니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

------
#### [ Bitbucket ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections**, **OAuth**, **앱 암호** 또는 **개인 액세스 토큰**을 선택하여 CodeBuild에 연결합니다.

 **연결**   
Bitbucket 연결 또는 Secrets Manager 암호를 선택하여 지정된 연결 유형을 통해 연결합니다.

 **리포지토리**   
**내 Bitbucket 계정의 리포지토리** 또는 **퍼블릭 리포지토리**를 선택하고 리포지토리 URL을 입력합니다.

 **소스 버전**   
분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 섹션을 참조하세요.  
**상태 컨텍스트**의 경우 Bitbucket 커밋 상태의 `name` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 Bitbucket API 설명서의 [빌드](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build)를 참조하세요.  
**대상 URL**에 Bitbucket 커밋 상태의 `url` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 Bitbucket API 설명서의 [빌드](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build)를 참조하세요.  
Webhook에 의해 트리거된 빌드의 상태는 항상 소스 공급자에게 보고됩니다. 콘솔 또는 API 직접 호출에서 시작된 빌드의 상태를 소스 공급자에게 보고하려면 이 설정을 선택해야 합니다.  
프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

코드 변경 사항이 이 리포지토리에 푸시될 때마다 CodeBuild가 소스 코드를 빌드하도록 하려면 **기본 소스 webhook 이벤트**에서 **코드 변경이 이 리포지토리에 푸시될 때마다 다시 빌드**를 선택합니다. webhook 및 필터 그룹에 대한 자세한 내용은 [Bitbucket Webhook 이벤트](bitbucket-webhook.md) 섹션을 참조하세요.

------
#### [ GitHub ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**GitHub 앱**, **OAuth** 또는 **개인 액세스 토큰**을 선택하여 CodeBuild에 연결합니다.

 **연결**   
GitHub 연결 또는 Secrets Manager 보안 암호를 선택하여 지정된 연결 유형을 통해 연결합니다.

 **리포지토리**   
**내 GitHub 계정의 리포지토리**, **퍼블릭 리포지토리** 또는 **GitHub 범위 웹후크**를 선택하고 리포지토리 URL을 입력합니다.

 **소스 버전**   
분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 섹션을 참조하세요.  
**상태 컨텍스트**의 경우 GitHub 커밋 상태의 `context` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
**대상 URL**에 GitHub 커밋 상태의 `target_url` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
Webhook에 의해 트리거된 빌드의 상태는 항상 소스 공급자에게 보고됩니다. 콘솔 또는 API 직접 호출에서 시작된 빌드의 상태를 소스 공급자에게 보고하려면 이 설정을 선택해야 합니다.  
프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

코드 변경 사항이 이 리포지토리에 푸시될 때마다 CodeBuild가 소스 코드를 빌드하도록 하려면 **기본 소스 webhook 이벤트**에서 **코드 변경이 이 리포지토리에 푸시될 때마다 다시 빌드**를 선택합니다. webhook 및 필터 그룹에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.

------
#### [ GitHub Enterprise Server ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections** 또는 **개인 액세스 토큰**을 선택하여 CodeBuild에 연결합니다.

 **연결**   
GitHub Enterprise 연결 또는 Secrets Manager 보안 암호를 선택하여 지정된 연결 유형을 통해 연결합니다.

 **리포지토리**   
**내 GitHub Enterprise 계정의 리포지토리** 또는 **GitHub Enterprise 범위 웹후크**를 선택하고 리포지토리 URL을 입력합니다.

**소스 버전**  
풀 요청, 분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

**Git clone 깊이**  
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 섹션을 참조하세요.  
**상태 컨텍스트**의 경우 GitHub 커밋 상태의 `context` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
**대상 URL**에 GitHub 커밋 상태의 `target_url` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
Webhook에 의해 트리거된 빌드의 상태는 항상 소스 공급자에게 보고됩니다. 콘솔 또는 API 직접 호출에서 시작된 빌드의 상태를 소스 공급자에게 보고하려면 이 설정을 선택해야 합니다.  
프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

**비보안 SSL**  
GitHub Enterprise 프로젝트 리포지토리에 연결되어 있는 동안 SSL을 무시하려면 **Enable insecure SSL(안전하지 않은 SSL 활성화)**을 선택합니다.

코드 변경 사항이 이 리포지토리에 푸시될 때마다 CodeBuild가 소스 코드를 빌드하도록 하려면 **기본 소스 webhook 이벤트**에서 **코드 변경이 이 리포지토리에 푸시될 때마다 다시 빌드**를 선택합니다. webhook 및 필터 그룹에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.

------
#### [ GitLab ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections**는 GitLab을 CodeBuild에 연결하는 데 사용됩니다.

 **연결**   
CodeConnections를 통해 연결할 GitLab 연결을 선택합니다.

 **리포지토리**   
사용할 리포지토리를 선택합니다.

 **소스 버전**   
pull 요청, 분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 섹션을 참조하세요.

------
#### [ GitLab Self Managed ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections**는 GitLab Self Managed를 CodeBuild 연결하는 데 사용됩니다.

 **연결**   
GitLab Self Managed 연결을 선택하여 CodeConnections 통해 연결합니다.

 **리포지토리**   
사용할 리포지토리를 선택합니다.

 **소스 버전**   
pull 요청, 분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 섹션을 참조하세요.

------

### 환경
<a name="create-project-console-environment"></a>

**프로비저닝 모델**  
다음 중 하나를 수행합니다.  
+ AWS CodeBuild에서 관리하는 온디맨드 플릿을 사용하려면 **온디맨드**를 선택합니다. CodeBuild는 온디맨드 플릿을 통해 빌드에 맞는 컴퓨팅 기능을 제공합니다. 빌드가 완료되면 머신이 파괴됩니다. 온디맨드 플릿은 완전 관리형이며, 수요 급증을 처리할 수 있는 자동 규모 조정 기능이 포함되어 있습니다.
+ AWS CodeBuild에서 관리하는 예약 용량 플릿을 사용하려면 **예약 용량**을 선택한 다음 **플릿 이름**을 선택합니다. 예약 용량 플릿을 사용하면 빌드 환경을 위한 전용 인스턴스 세트를 구성할 수 있습니다. 이러한 머신은 유휴 상태로 유지되므로 빌드 또는 테스트를 즉시 처리하고 빌드 기간을 단축할 수 있습니다. 예약 용량 플릿을 사용하면 머신이 상시 가동되므로 프로비저닝하는 한 계속해서 비용이 발생합니다.
자세한 내용은 [예약 용량 플릿에서 빌드 실행](fleets.md) 섹션을 참조하세요.

**환경 이미지**  <a name="environment-image.console"></a>
다음 중 하나를 수행합니다.  
+ AWS CodeBuild가 관리하는 도커 이미지를 사용하려면 **Managed image(관리형 이미지)**를 선택한 후 **운영 체제**, **런타임**, **이미지** 및 **이미지 버전**에서 항목을 선택합니다. 사용 가능한 경우 **환경 유형**에서 항목을 선택합니다.
+ 다른 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Other registry(다른 레지스트리)**를 선택한 경우 **External registry URL(외부 레지스트리 URL)**에 Docker Hub의 도커 이미지 이름 및 태그를 `docker repository/docker image name` 형식으로 입력합니다. **Amazon ECR**을 선택하는 경우 **Amazon ECR 리포지토리** 및 **Amazon ECR 이미지**를 사용하여 AWS 계정의 Docker 이미지를 선택합니다.
+ 프라이빗 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Image registry(이미지 레지스트리)**에서 **Other registry(다른 레지스트리)**를 선택한 다음 프라이빗 도커 이미지에 대한 보안 인증 정보의 ARN을 입력합니다. 보안 인증은 Secrets Manager에서 생성됩니다. 자세한 내용은 AWS Secrets Manager 사용 설명서의 [AWS Secrets Manager이란?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) 섹션을 참조하세요.**
CodeBuild는 사용자 지정 도커 이미지에 대해 `ENTRYPOINT`를 재정의합니다.

**컴퓨팅**  
다음 중 하나를 수행합니다.  
+ EC2 컴퓨팅을 사용하려면 **EC2**를 선택합니다. EC2 컴퓨팅은 작업 실행 중에 최적화된 유연성을 제공합니다.
+ Lambda 컴퓨팅을 사용하려면 **Lambda**를 선택합니다. Lambda 컴퓨팅은 빌드에 최적화된 시작 속도를 제공합니다. Lambda는 시작 지연 시간이 짧아 더 빠른 빌드를 지원합니다. Lambda도 자동으로 확장되므로 빌드가 실행 대기열에서 대기하지 않습니다. 자세한 내용은 [AWS Lambda 컴퓨팅 기반 빌드 실행](lambda.md) 섹션을 참조하세요.

**서비스 역할**  
다음 중 하나를 수행합니다.  
+ CodeBuild 서비스 역할이 없는 경우 **새 서비스 역할**을 선택합니다. **역할 이름**에 새 역할의 이름을 입력합니다.
+ CodeBuild 서비스 역할이 있는 경우 **기존 서비스 역할**을 선택합니다. **역할 ARN**에서 서비스 역할을 선택합니다.
콘솔을 사용하여 빌드 프로젝트를 생성하는 경우, 이와 동시에 CodeBuild 서비스 역할을 생성할 수 있습니다. 기본적으로 역할은 해당 빌드 프로젝트에서만 작동합니다. 콘솔을 사용하여 이 서비스 역할을 다른 빌드 프로젝트와 연결하는 경우 다른 빌드 프로젝트에서 작동하도록 역할이 업데이트됩니다. 하나의 서비스 역할은 최대 10개의 빌드 프로젝트에서 작동할 수 있습니다.

**추가 구성**    
**자동 재시도 제한**  
빌드 실패 후 추가 자동 재시도 횟수를 지정합니다. 예를 들어 자동 재시도 제한이 2로 설정된 경우 CodeBuild는 `RetryBuild` API를 호출하여 빌드를 추가로 최대 2회 자동 재시도합니다.  
**제한 시간**  
빌드가 완료되지 않는 경우 CodeBuild가 해당 빌드를 중지할 제한 시간으로 5분에서 36시간 사이의 값을 지정합니다. [**hours**] 및 [**minutes**]가 비어 있는 경우 기본값인 60분이 사용됩니다.  
**권한 있음**  
(선택 사항) 이 빌드 프로젝트를 사용하여 Docker 이미지를 빌드하려는 경우에만 **Docker 이미지를 빌드하거나 빌드에서 승격된 권한을 얻으려는 경우 이 플래그 활성화**를 선택합니다. 그렇지 않으면 Docker 데몬과 상호 작용을 시도하는 모든 연결된 빌드가 실패합니다. 또한 빌드가 상호 작용할 수 있도록 Docker 데몬을 시작해야 합니다. 이를 수행하는 한 가지 방법은 다음 빌드 명령을 실행하여 빌드 사양의 `install` 단계에서 Docker 데몬을 초기화하는 것입니다. 선택한 빌드 환경 이미지가 Docker 지원을 통해 CodeBuild에서 제공되지 않는 경우 이 명령을 실행하지 마세요.  
기본적으로 비 VPC 빌드에는 Docker 데몬이 활성화됩니다. VPC 빌드에 Docker 컨테이너를 사용하려면 Docker Docs 웹 사이트의 [런타임 권한 및 Linux 기능](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)을 참조하고 권한 부여 모드를 활성화합니다. 또한 Windows는 권한 모드를 지원하지 않습니다.

```
- nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 &
- timeout 15 sh -c "until docker info; do echo .; sleep 1; done"
```  
**VPC**   
CodeBuild를 사용하여 VPC에서 작업을 수행하려는 경우:  
+ **VPC**에서 CodeBuild가 사용하는 VPC ID를 선택합니다.
+ **VPC 서브넷**에서 CodeBuild가 사용하는 리소스가 포함된 서브넷을 선택합니다.
+ **VPC 보안 그룹**에서 CodeBuild가 VPC의 리소스에 대한 액세스를 허용하기 위해 사용하는 보안 그룹을 선택합니다.
자세한 내용은 [Amazon Virtual Private Cloud AWS CodeBuild 와 함께 사용](vpc-support.md) 섹션을 참조하세요.  
**컴퓨팅**  
사용 가능한 옵션 중 하나를 선택합니다.  
**레지스트리 자격 증명**  
프로젝트가 비공개 레지스트리 이미지로 구성된 경우 레지스트리 자격 증명을 지정합니다.  
이 자격 증명은 이미지가 프라이빗 레지스트리의 이미지로 재정의된 경우에만 사용됩니다.  
**환경 변수**:  
사용할 빌드의 각 환경 변수에 대해 이름 및 값을 입력하고 유형을 선택합니다.  
CodeBuild는 AWS 리전의 환경 변수를 자동으로 설정합니다. buildspec.yml에 추가하지 않은 경우 다음 환경 변수를 설정해야 합니다.  
+ AWS\$1ACCOUNT\$1ID
+ IMAGE\$1REPO\$1NAME
+ IMAGE\$1TAG
콘솔 및 AWS CLI 사용자는 환경 변수를 확인할 수 있습니다. 환경 변수의 가시성에 대한 문제가 없다면 [**Name**] 및 [**Value**] 필드를 설정한 다음 [**Type**]을 [**Plaintext**]로 설정합니다.  
AWS 액세스 키 ID, AWS 비밀 액세스 키 또는 암호와 같은 중요한 값을 가진 환경 변수는 Amazon EC2 Systems Manager Parameter Store 또는 AWS Secrets Manager에 파라미터로 저장하는 것이 좋습니다.  
Amazon EC2 Systems Manager Parameter Store를 사용하는 경우 **유형**에서 **파라미터**를 선택합니다. **이름**에 CodeBuild가 참조할 식별자를 입력합니다. **값**에 Amazon EC2 Systems Manager Parameter Store에 저장되는 파라미터의 이름을 입력합니다. 예를 들어 `/CodeBuild/dockerLoginPassword`라는 이름의 파라미터를 사용하여 **유형**에서 **파라미터**를 선택합니다. **이름**에 `LOGIN_PASSWORD`를 입력합니다. **값**에 `/CodeBuild/dockerLoginPassword`를 입력합니다.  
Amazon EC2 Systems Manager Parameter Store를 사용하는 경우 `/CodeBuild/`로 시작하는 파라미터 이름(예: `/CodeBuild/dockerLoginPassword`)으로 파라미터를 저장하는 것이 좋습니다. CodeBuild 콘솔을 사용하여 Amazon EC2 Systems Manager에서 파라미터를 생성할 수 있습니다. **파라미터 생성**을 선택하고 대화 상자에 표시되는 지시에 따릅니다. 대화 상자의 **KMS 키**에 해당 계정의 AWS KMS 키에 대한 ARN을 지정할 수 있습니다. Amazon EC2 Systems Manager는 이 키를 사용하여 저장 시 파라미터의 값을 암호화하고 검색 시 암호를 해독합니다. CodeBuild 콘솔을 사용하여 파라미터를 생성하는 경우 콘솔은 이름이 `/CodeBuild/`인 파라미터가 저장되면 시작합니다. 자세한 내용은 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)을 참조하세요.**  
빌드 프로젝트가 Amazon EC2 Systems Manager Parameter Store에 저장된 파라미터를 참조하는 경우 해당 빌드 프로젝트의 서비스 역할은 `ssm:GetParameters` 작업을 허용해야 합니다. 앞에서 **새 서비스 역할**을 선택한 경우에는 CodeBuild는 빌드 프로젝트의 기본 서비스 역할에 이 작업을 포함합니다. **Existing service role(기존 서비스 역할)**을 선택한 경우에는 이 작업을 서비스 역할에 별도로 포함해야 합니다.  
빌드 프로젝트가 `/CodeBuild/`로 시작되지 않는 파라미터 이름으로 Amazon EC2 Systems Manager Parameter Store에 저장된 파라미터를 참조하는 경우 **새 서비스 역할**을 선택하면 `/CodeBuild/`로 시작하지 않는 파라미터 이름에 액세스할 수 있도록 해당 서비스 역할을 업데이트해야 합니다. 이는 서비스 역할이 `/CodeBuild/`로 시작하는 파라미터 이름에만 액세스할 수 있기 때문입니다.  
**새 서비스 역할**을 선택하면 Amazon EC2 Systems Manager Parameter Store에 있는 `/CodeBuild/` 네임스페이스의 모든 파라미터를 해독할 권한이 서비스 역할에 포함됩니다.  
사용자가 설정한 환경 변수는 기존 환경 변수를 대체합니다. 예를 들어 도커 이미지에 값이 `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_`로 시작하는 이름으로 환경 변수를 설정하지 마십시오. 이 접두사는 내부 전용으로 예약되어 있습니다.  
여러 위치에서 동일한 이름의 환경 변수가 정의되는 경우, 다음과 같이 값이 결정됩니다.  
+ 시작 빌드 작업 호출의 값이 가장 높은 우선 순위를 갖습니다.
+ 빌드 프로젝트 정의의 값이 다음 우선 순위를 갖습니다.
+ buildspec 선언의 값이 가장 낮은 우선 순위를 갖습니다.
Secrets Manager를 사용하는 경우 **유형**으로 **Secrets Manager**로 선택합니다. **이름**에 CodeBuild가 참조할 식별자를 입력합니다. **값**에 `secret-id:json-key:version-stage:version-id` 패턴을 사용하여 `reference-key`를 입력합니다. 자세한 내용은 [Secrets Manager reference-key in the buildspec file](build-spec-ref.md#secrets-manager-build-spec) 섹션을 참조하세요.  
Secrets Manager를 사용하는 경우 이름이 `/CodeBuild/`로 시작하는 암호를 저장하는 것이 좋습니다(예: `/CodeBuild/dockerLoginPassword`). 자세한 내용은 AWS Secrets Manager 사용 설명서의 [AWS Secrets Manager이란?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 섹션을 참조하세요.**  
빌드 프로젝트가 Secrets Manager에 저장된 암호를 참조하는 경우 해당 빌드 프로젝트의 서비스 역할은 `secretsmanager:GetSecretValue` 작업을 허용해야 합니다. 앞에서 **새 서비스 역할**을 선택한 경우에는 CodeBuild는 빌드 프로젝트의 기본 서비스 역할에 이 작업을 포함합니다. **Existing service role(기존 서비스 역할)**을 선택한 경우에는 이 작업을 서비스 역할에 별도로 포함해야 합니다.  
빌드 프로젝트가 `/CodeBuild/`로 시작되지 않는 보안 암호 이름으로 Secrets Manager에 저장된 암호를 참조하는 경우 **새 서비스 역할**을 선택하면 `/CodeBuild/`로 시작하지 않는 보안 암호 이름에 액세스할 수 있도록 해당 서비스 역할을 업데이트해야 합니다. 이는 서비스 역할이 `/CodeBuild/`로 시작하는 암호 이름에만 액세스할 수 있기 때문입니다.  
**새 서비스 역할**을 선택하면 에 있는 `/CodeBuild/` 네임스페이스의 모든 암호를 해독할 권한이 서비스 역할에 포함됩니다.

### Buildspec
<a name="create-project-console-buildspec"></a>

**빌드 사양**  
다음 중 하나를 수행합니다.  
+ 소스 코드에 buildspec 파일이 있는 경우 **Use a buildspec file(빌드 사양 파일 사용)** 을 선택합니다. 기본적으로 CodeBuild는 소스 코드 루트 디렉터리에서 `buildspec.yml`이라는 파일을 찾습니다. buildspec 파일이 다른 이름이나 위치를 사용하는 경우 **Buildspec 이름**에 소스 루트의 경로를 입력합니다(예: `buildspec-two.yml` 또는 `configuration/buildspec.yml`). buildspec 파일이 S3 버킷에 있는 경우 해당 파일은 빌드 프로젝트와 동일한 AWS 리전에 있어야 합니다. ARN을 사용하여 buildspec 파일을 지정합니다(예: `arn:aws:s3:::<my-codebuild-sample2>/buildspec.yml`).
+ 소스 코드에 buildspec 파일이 포함되어 있지 않거나, 소스 코드의 루트 디렉터리에 있는 `buildspec.yml` 파일의 `build` 단계에 지정된 것과 다른 빌드 명령 세트를 실행하려는 경우 **빌드 명령 삽입**을 선택합니다. **빌드 명령**의 `build` 단계에서 실행하려는 명령을 입력합니다. 명령이 여러 개인 경우 각 명령을 `&&`로 구분합니다(예: `mvn test && mvn package`). 다른 구문에서 명령을 실행하려는 경우 또는 `build` 단계에 대해 특히 긴 명령 목록이 있는 경우에는 소스 코드 루트 디렉터리에 `buildspec.yml` 파일을 추가하고, 이 파일에 명령을 추가한 다음, **소스 코드 루트 디렉터리에서 buildspec.yml 사용**을 선택합니다.
자세한 내용은 [buildspec 참조](build-spec-ref.md)을 참조하세요.

### 배치 구성
<a name="create-project-console-batch-config"></a>

빌드 그룹을 단일 작업으로 실행할 수 있습니다. 자세한 내용은 [배치로 빌드 실행](batch-build.md) 섹션을 참조하세요.

**배치 구성 정의**  
이 프로젝트에서 배치 빌드를 허용하려면 선택합니다.

**배치 서비스 역할**  
배치 빌드에 대한 서비스 역할을 제공합니다.  
다음 중 하나를 선택합니다.  
+ 배치 서비스 역할이 없는 경우 **새 서비스 역할**을 선택합니다. **서비스 역할**에 새 역할의 이름을 입력합니다.
+ 배치 서비스 역할이 있는 경우 **기존 서비스 역할**을 선택합니다. **서비스 역할**에서 서비스 역할을 선택합니다.
배치 빌드는 배치 구성에 새로운 보안 역할을 도입합니다. CodeBuild가 사용자 대신 `StartBuild`, `StopBuild` 및 `RetryBuild` 작업을 호출하여 배치의 일부로 빌드를 실행할 수 있어야 하므로 이 새 역할이 필요합니다. 고객은 다음과 같은 두 가지 이유로 빌드에 사용하는 것과 동일한 역할이 아닌 새 역할을 사용해야 합니다.  
+ 빌드 역할 `StartBuild`, `StopBuild` 및 `RetryBuild` 권한을 부여하면 단일 빌드에서 buildspec을 통해 더 많은 빌드를 시작할 수 있습니다.
+ CodeBuild 배치 빌드는 배치의 빌드에 사용할 수 있는 빌드 및 컴퓨팅 유형의 수를 제한하는 제한을 제공합니다. 빌드 역할에 이러한 권한이 있는 경우 빌드 자체가 이러한 제한을 우회할 수 있습니다.

**배치에 허용되는 컴퓨팅 유형**  
배치에 허용되는 컴퓨팅 유형을 선택합니다. 해당하는 항목을 모두 선택합니다.

**배치에 허용되는 플릿**  
배치에 허용되는 플릿을 선택합니다. 해당하는 항목을 모두 선택합니다.

**배치에 허용되는 최대 빌드 수**  
배치에 허용되는 최대 빌드 수를 입력합니다. 이 제한을 초과하는 배치는 실패합니다.

**배치 제한 시간**  
배치 빌드가 완료되는 최대 시간을 입력합니다.

**아티팩트 결합**  
**배치의 모든 아티팩트를 단일 위치로 결합**을 선택하면 배치의 모든 아티팩트가 단일 위치로 결합됩니다.

 **배치 보고서 모드**   
배치 빌드에 대해 원하는 빌드 상태 보고서 모드를 선택합니다.  
이 필드는 프로젝트 소스가 Bitbucket, GitHub 또는 GitHub Enterprise이고 **소스**에서 **빌드 시작 및 종료 시 소스 공급자에게 빌드 상태 보고**를 선택한 경우에만 사용할 수 있습니다.  
 **빌드 집계**   
배치의 모든 빌드 상태를 단일 상태 보고서로 통합하려면 선택합니다.  
 **개별 빌드**   
배치에 있는 모든 빌드의 빌드 상태를 별도로 보고하려면 선택합니다.

### Artifacts
<a name="create-project-console-artifacts"></a>

**유형**  
다음 중 하나를 수행합니다.  
+ 빌드 출력 결과물을 생성하지 않으려면 [**No artifacts**]를 선택합니다. 빌드 테스트만 실행하고 있는 경우 또는 Amazon ECR 리포지토리에 도커 이미지를 푸시하려는 경우에 이 작업을 원할 수 있습니다.
+ S3 버킷에 빌드 출력을 저장하려면 **Amazon S3**를 선택하고 다음 작업을 수행합니다.
  + 빌드 출력 ZIP 파일이나 폴더에 프로젝트 이름을 사용하려는 경우 **이름**을 비워 둡니다. 그렇지 않으면 이름을 입력합니다. (ZIP 파일을 출력하고 ZIP 파일에 파일 확장명을 넣으려는 경우, ZIP 파일 이름 뒤에 이를 포함하십시오.)
  + buildspec 파일에 지정된 이름으로 콘솔에서 지정한 이름을 재정의하려는 경우 **의미 체계 버전 관리 사용**을 선택합니다. buildspec 파일의 이름은 빌드 시 계산되며 Shell 명령 언어를 사용합니다. 예를 들어 결과물 이름이 항상 고유하도록 날짜와 시간을 결과물 이름에 추가할 수 있습니다. 고유한 결과물 이름을 사용하면 결과물을 덮어쓰지 않을 수 있습니다. 자세한 내용은 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax) 섹션을 참조하세요.
  + [**Bucket name**]에서 출력 버킷의 이름을 선택합니다.
  + 이 절차의 앞부분에서 **빌드 명령 삽입**을 선택한 경우 **출력 파일**에 빌드 출력 ZIP 파일 또는 폴더에 넣으려는 빌드의 파일 위치를 입력합니다. 위치가 여러 개인 경우 각 위치를 쉼표로 구분합니다(예: `appspec.yml, target/my-app.jar`). 자세한 내용은 `files`의 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax) 설명을 참조하십시오.
  + 빌드 아티팩트를 암호화하지 않으려면 **Remove artifacts encryption(결과물 암호화 제거)**을 선택합니다.
각각 원하는 보조 아티팩트 세트마다 다음과 같이 실행합니다.  

1. **Atrifact identifier(아티팩트 식별자)**에서 128자 미만으로 영숫자와 밑줄만 포함된 값을 입력합니다.

1. **Add artifact(아티팩트 추가)**를 선택합니다.

1. 이전 단계에 따라 보조 결과물을 구성합니다.

1. **Save artifact(아티팩트 저장)**를 선택합니다.

**추가 구성**    
**암호화 키**  
(선택 사항) 다음 중 하나를 수행하십시오.  
+ 계정에서 Amazon S3에 대한 AWS 관리형 키를 사용하여 빌드 출력 아티팩트를 암호화하려면 **암호화 키**를 비워 둡니다. 이 값이 기본값입니다.
+ 고객 관리형 키를 사용하여 빌드 출력 아티팩트를 암호화하려면 **암호화 키**에 KMS 키의 ARN을 입력합니다. `arn:aws:kms:region-ID:account-ID:key/key-ID` 형식을 사용합니다.  
**캐시 유형**  
**Cache type(캐시 유형)**에서 다음 중 하나를 선택합니다.  
+ 캐시를 사용하지 않으려면 [**No cache**]를 선택합니다.
+ Amazon S3 캐시를 사용하려면 **Amazon S3**를 선택하고 다음을 수행합니다.
  + **버킷**에서 캐시가 저장된 S3 버킷의 이름을 선택합니다.
  + (선택 사항) **캐시 경로 접두사**에 Amazon S3 경로 접두사를 입력합니다. **Cache path prefix(캐시 경로 접두사)** 값은 디렉터리 이름과 비슷합니다. 따라서 캐시를 버킷의 동일한 디렉터리에 저장할 수 있습니다.
**중요**  
경로 접두사 끝에 후행 슬래시(/)를 추가하지 마십시오.
+  로컬 캐시를 사용하려면 **로컬**을 선택한 다음 하나 이상의 로컬 캐시 모드를 선택해야 합니다.
**참고**  
Docker 계층 캐시 모드는 Linux에서만 사용할 수 있습니다. 이 모드를 선택할 경우 프로젝트를 권한이 있는 모드에서 실행해야 합니다.
캐시를 사용하면 빌드 환경의 재사용 가능한 특정 부분이 캐시에 저장되고 빌드 전반에서 사용되기 때문에 상당한 빌드 시간을 절약할 수 있습니다. buildspec 파일에 캐시를 지정하는 것에 대한 자세한 정보는 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax) 단원을 참조하십시오. 캐싱에 대한 자세한 정보는 [성능을 개선하기 위한 캐시 빌드](build-caching.md)을 참조하세요.

### 로그
<a name="create-project-console-logs"></a>

생성하려는 로그를 선택합니다. Amazon CloudWatch Logs 또는 Amazon S3 로그 중 하나 또는 둘 다를 생성할 수 있습니다.

**CloudWatch**:  
Amazon CloudWatch Logs 로그를 원할 경우:    
**CloudWatch 로그**  
**CloudWatch 로그**를 선택합니다.  
**그룹 이름**  
Amazon CloudWatch Logs 로그 그룹의 이름을 입력합니다.  
**스트림 이름**  
Amazon CloudWatch Logs 로그 스트림 이름을 입력합니다.

**S3**  
Amazon S3 로그를 원할 경우:    
**S3 로그**  
**S3 로그**를 선택합니다.  
** 버킷**  
로그에 대한 S3 버킷 이름을 선택합니다.  
**경로 접두사**  
로그의 접두사를 입력합니다.  
**S3 로그 암호화 비활성화**  
S3 로그를 암호화하지 않으려면 선택합니다.

## 빌드 프로젝트 생성(AWS CLI)
<a name="create-project-cli"></a>

AWS CLI와 CodeBuild를 함께 사용하는 방법에 대한 자세한 내용은 [명령줄 참조](cmd-ref.md) 섹션을 참조하세요.

AWS CLI를 사용하여 CodeBuild 빌드 프로젝트를 생성하려면 JSON 형식의 [프로젝트](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Project.html) 구조를 생성하고, 구조를 채우고, [https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html) 명령을 호출하여 프로젝트를 생성합니다.

### JSON 파일 생성
<a name="cp-cli-create-file"></a>

`--generate-cli-skeleton` 옵션을 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html) 명령으로 스켈레톤 JSON 파일을 생성합니다.

```
aws codebuild create-project --generate-cli-skeleton > <json-file>
```

이렇게 하면 *<json-file>*로 지정된 경로와 파일 이름을 가진 JSON 파일이 생성됩니다.

### JSON 파일 채우기
<a name="cp-cli-fill-in-file"></a>

JSON 데이터를 다음과 같이 수정하고 결과를 저장합니다.

```
{
  "name": "<project-name>",
  "description": "<description>",
  "source": {
    "type": "CODECOMMIT" | "CODEPIPELINE" | "GITHUB" | "GITHUB_ENTERPRISE" | "GITLAB" | "GITLAB_SELF_MANAGED" | "BITBUCKET" | "S3" | "NO_SOURCE",
    "location": "<source-location>",
    "gitCloneDepth": "<git-clone-depth>",
    "buildspec": "<buildspec>",
    "InsecureSsl": "<insecure-ssl>",
    "reportBuildStatus": "<report-build-status>",
    "buildStatusConfig": {
      "context": "<context>",
      "targetUrl": "<target-url>"
    },
    "gitSubmodulesConfig": {
      "fetchSubmodules": "<fetch-submodules>"
    },
    "auth": {
      "type": "<auth-type>",
      "resource": "<auth-resource>"
    },
    "sourceIdentifier": "<source-identifier>"
  },
  "secondarySources": [
    {
        "type": "CODECOMMIT" | "CODEPIPELINE" | "GITHUB" | "GITHUB_ENTERPRISE" | "GITLAB" | "GITLAB_SELF_MANAGED" | "BITBUCKET" | "S3" | "NO_SOURCE",
        "location": "<source-location>",
        "gitCloneDepth": "<git-clone-depth>",
        "buildspec": "<buildspec>",
        "InsecureSsl": "<insecure-ssl>",
        "reportBuildStatus": "<report-build-status>",
        "auth": {
          "type": "<auth-type>",
          "resource": "<auth-resource>"
        },
        "sourceIdentifier": "<source-identifier>"
    }
  ],
  "secondarySourceVersions": [
    {
      "sourceIdentifier": "<secondary-source-identifier>",
      "sourceVersion": "<secondary-source-version>"
    }
  ],
  "sourceVersion": "<source-version>",
  "artifacts": {
    "type": "CODEPIPELINE" | "S3" | "NO_ARTIFACTS",
    "location": "<artifacts-location>",
    "path": "<artifacts-path>",
    "namespaceType": "<artifacts-namespacetype>",
    "name": "<artifacts-name>",
    "overrideArtifactName": "<override-artifact-name>",
    "packaging": "<artifacts-packaging>"
  },
  "secondaryArtifacts": [
    {
      "type": "CODEPIPELINE" | "S3" | "NO_ARTIFACTS",
      "location": "<secondary-artifact-location>",
      "path": "<secondary-artifact-path>",
      "namespaceType": "<secondary-artifact-namespaceType>",
      "name": "<secondary-artifact-name>",
      "packaging": "<secondary-artifact-packaging>",
      "artifactIdentifier": "<secondary-artifact-identifier>"
    }
  ],
  "cache": {
    "type": "<cache-type>",
    "location": "<cache-location>",
    "mode": [
      "<cache-mode>"
    ]
  },
  "environment": {
    "type": "LINUX_CONTAINER" | "LINUX_GPU_CONTAINER" | "ARM_CONTAINER" | "WINDOWS_SERVER_2019_CONTAINER" | "WINDOWS_SERVER_2022_CONTAINER",
    "image": "<image>",
    "computeType": "BUILD_GENERAL1_SMALL" | "BUILD_GENERAL1_MEDIUM" | "BUILD_GENERAL1_LARGE" | "BUILD_GENERAL1_2XLARGE",
    "certificate": "<certificate>",
    "environmentVariables": [
      {
        "name": "<environmentVariable-name>",
        "value": "<environmentVariable-value>",
        "type": "<environmentVariable-type>"
      }
    ],
    "registryCredential": [
      {
        "credential": "<credential-arn-or-name>",
        "credentialProvider": "<credential-provider>"
      }
    ],
    "imagePullCredentialsType": "CODEBUILD" | "SERVICE_ROLE",
    "privilegedMode": "<privileged-mode>"
  },
  "serviceRole": "<service-role>",
  "autoRetryLimit": <auto-retry-limit>,
  "timeoutInMinutes": <timeout>,
  "queuedTimeoutInMinutes": <queued-timeout>,
  "encryptionKey": "<encryption-key>",
  "tags": [
    {
      "key": "<tag-key>",
      "value": "<tag-value>"
    }
  ],
  "vpcConfig": {
    "securityGroupIds": [
         "<security-group-id>"
    ],
    "subnets": [
         "<subnet-id>"
    ],
    "vpcId": "<vpc-id>"
  },
  "badgeEnabled": "<badge-enabled>",
  "logsConfig": {
    "cloudWatchLogs": {
      "status": "<cloudwatch-logs-status>",
      "groupName": "<group-name>",
      "streamName": "<stream-name>"
    },
    "s3Logs": {
      "status": "<s3-logs-status>",
      "location": "<s3-logs-location>",
      "encryptionDisabled": "<s3-logs-encryption-disabled>"
    }
  },
  "fileSystemLocations": [
    {
      "type": "EFS",
      "location": "<EFS-DNS-name-1>:/<directory-path>",
      "mountPoint": "<mount-point>",
      "identifier": "<efs-identifier>",
      "mountOptions": "<efs-mount-options>"
    }
  ],
  "buildBatchConfig": {
    "serviceRole": "<batch-service-role>",
    "combineArtifacts": <combine-artifacts>,
    "restrictions": {
      "maximumBuildsAllowed": <max-builds>,
      "computeTypesAllowed": [
        "<compute-type>"
      ],
      "fleetsAllowed": [
        "<fleet-name>"
      ]
    },
    "timeoutInMins": <batch-timeout>,
    "batchReportMode": "REPORT_AGGREGATED_BATCH" | "REPORT_INDIVIDUAL_BUILDS"
  },
  "concurrentBuildLimit": <concurrent-build-limit>
}
```

다음을 바꿉니다.

#### **.name**
<a name="cli.project-name"></a>

필수 사항입니다. 이 빌드 프로젝트의 이름입니다. 이 이름은 AWS 계정에 있는 모든 빌드 프로젝트에서 고유해야 합니다.

#### **설명**
<a name="cli.description"></a>

선택 사항입니다. 이 빌드 프로젝트의 설명입니다.

#### **소스**
<a name="cli.source"></a>

필수 사항입니다. 이 빌드 프로젝트의 소스 코드 설정에 대한 정보가 들어 있는 [ProjectSource](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html) 객체입니다. `source` 객체를 추가한 후에는 [**secondarySources**](#cli.secondarysources)를 사용해 소스를 최대 12개까지 더 추가할 수 있습니다. 이러한 설정에는 다음이 포함됩니다.

source/**type**  <a name="cli.source.type"></a>
필수 사항입니다. 빌드할 소스 코드가 포함된 리포지토리의 유형입니다. 유효한 값으로는 다음이 포함됩니다.  
+ `CODECOMMIT`
+ `CODEPIPELINE`
+ `GITHUB`
+ `GITHUB_ENTERPRISE`
+ `GITLAB`
+ `GITLAB_SELF_MANAGED`
+ `BITBUCKET`
+ `S3`
+ `NO_SOURCE`
`NO_SOURCE`를 사용할 경우 프로젝트에 소스가 없으므로 buildspec은 파일이 될 수 없습니다. 대신에 `buildspec` 속성을 사용하여 buildspec에 대해 YAML 형식이 지정된 문자열을 지정해야 합니다. 자세한 내용은 [소스 없이 빌드 프로젝트 생성](no-source.md) 섹션을 참조하세요.

source/**location**  <a name="cli.source.location"></a>
*<source-type>*을 `CODEPIPELINE`으로 설정하지 않은 경우 필수입니다. 지정한 리포지토리 유형의 소스 코드 위치입니다.  
+ CodeCommit의 경우 HTTPS가 소스 코드 및 buildspec 파일을 포함하는 리포지토리에 URL을 복제합니다(예: `https://git-codecommit.<region-id>.amazonaws.com/v1/repos/<repo-name>`).
+ Amazon S3의 경우 빌드 입력 버킷 이름 다음에 소스 코드 및 buildspec이 포함된 ZIP 파일의 경로와 이름이 옵니다. 예:
  + 입력 버킷의 루트에 있는 ZIP 파일의 경우: `<bucket-name>/<object-name>.zip`
  + 입력 버킷의 하위 폴더에 있는 ZIP 파일의 경우: `<bucket-name>/<subfoler-path>/<object-name>.zip`
+ GitHub의 경우 HTTPS가 소스 코드 및 buildspec 파일을 포함하는 리포지토리에 URL을 복제합니다. URL에 github.com이 포함되어야 합니다. AWS 계정을 GitHub 계정에 연결해야 합니다. 이렇게 하려면 CodeBuild 콘솔을 사용하여 빌드 프로젝트를 생성합니다.
  + [**Authorize application**]을 선택합니다. (GitHub 계정에 연결했으면 빌드 프로젝트 생성을 완료하지 않아도 됩니다. CodeBuild 콘솔을 닫아도 됩니다.) 
+ GitHub Enterprise Server의 경우 HTTP 또는 HTTPS가 소스 코드 및 buildspec 파일을 포함하는 리포지토리에 URL을 복제합니다. 또한 AWS 계정을 GitHub Enterprise Server 계정에도 연결해야 합니다. 이렇게 하려면 CodeBuild 콘솔을 사용하여 빌드 프로젝트를 생성합니다.

  1. GitHub Enterprise Server에서 개인용 액세스 토큰을 생성합니다.

  1. CodeBuild 프로젝트를 생성할 때 사용할 수 있도록 이 토큰을 클립보드에 복사합니다. 자세한 내용은 GitHub Help 웹 사이트의 [Creating a personal access token for the command line](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/)을 참조하십시오.

  1. 콘솔을 사용하여 CodeBuild 프로젝트를 생성하는 경우, **소스**의 **소스 공급자**에서 **GitHub Enterprise**를 선택합니다.

  1. [**Personal Access Token**]에서 클리보드에 복사한 토큰을 붙여 넣습니다. **토큰 저장**을 선택합니다. 이제 CodeBuild 계정이 GitHub Enterprise Server 계정에 연결되었습니다.
+ GitLab 및 GitLab self-managed의 경우 HTTPS가 소스 코드 및 buildspec 파일을 포함하는 리포지토리에 URL을 복제합니다. GitLab을 사용하는 경우 URL에 gitlab.com이 포함되어야 합니다. GitLab self-managed를 사용하는 경우 URL에 gitlab.com을 포함할 필요가 없습니다. AWS 계정을 GitLab 또는 GitLab self-managed 계정에 연결해야 합니다. 이렇게 하려면 CodeBuild 콘솔을 사용하여 빌드 프로젝트를 생성합니다.
  + 개발자 도구 탐색 창에서 **설정**, **연결**을 선택한 다음, **연결 생성**을 선택합니다. 이 페이지에서 GitLab 또는 GitLab self-managed 연결을 생성한 다음 **GitLab에 연결**을 선택합니다.
+ Bitbucket의 경우 HTTPS가 소스 코드 및 buildspec 파일을 포함하는 리포지토리에 URL을 복제합니다. URL에 bitbucket.org가 포함되어야 합니다. 또한 AWS 계정을 Bitbucket 계정에도 연결해야 합니다. 이렇게 하려면 CodeBuild 콘솔을 사용하여 빌드 프로젝트를 생성합니다.

  1. 콘솔을 사용하여 Bitbucket에 연결(또는 재연결)하면 Bitbucket [**Confirm access to your account**] 페이지에서 [**Grant access**]를 선택합니다. (Bitbucket 계정에 연결했으면 빌드 프로젝트 생성을 완료하지 않아도 됩니다. CodeBuild 콘솔을 닫아도 됩니다.) 
+ AWS CodePipeline의 경우 `location`에 `source` 값을 지정하지 마십시오. CodePipeline에서 파이프라인을 생성하면 파이프라인의 소스 단계에서 소스 코드 위치를 지정하게 되므로 이 값이 무시됩니다.

source/**gitCloneDepth**  <a name="cli.source.gitclonedepth"></a>
선택 사항입니다. 다운로드할 이력의 수준입니다. 최소값은 0입니다. 이 값이 0이거나, 25를 초과하거나, 지정되지 않은 경우 각 빌드 프로젝트에서 전체 이력이 다운로드됩니다. 소스 유형이 Amazon S3일 경우 이 값이 지원되지 않습니다.

source/**buildspec**  <a name="cli.source.buildspec"></a>
선택 사항입니다. 사용할 빌드 사양 정의 또는 파일입니다. 이 값을 제공하지 않거나 빈 문자열로 설정하는 경우 소스 코드에 루트 디렉터리의 `buildspec.yml` 파일이 포함되어 있어야 합니다. 이 값이 설정된 경우 인라인 buildspec 정의, 기본 소스의 루트 디렉터리에 상대적인 대체 buildspec 파일의 경로 또는 S3 버킷의 경로가 될 수 있습니다. 버킷은 빌드 프로젝트와 동일한 AWS 리전에 있어야 합니다. ARN을 사용하여 buildspec 파일을 지정합니다(예: `arn:aws:s3:::<my-codebuild-sample2>/buildspec.yml`). 자세한 내용은 [buildspec 파일 이름 및 스토리지 위치](build-spec-ref.md#build-spec-ref-name-storage) 섹션을 참조하세요.

source/**auth**  <a name="cli.source.auth"></a>
CodeBuild가 빌드할 소스 코드에 액세스하기 위한 권한 부여 설정에 대한 정보를 포함합니다.

source/auth/**type**  <a name="cli.source.auth.type"></a>
필수 사항입니다. 사용할 권한 부여 유형입니다. 유효한 값은 다음과 같습니다.  
+ `OAUTH`
+ `CODECONNECTIONS`
+ `SECRETS_MANAGER`

source/auth/**resource**  <a name="cli.source.auth.resource"></a>
선택 사항입니다. 지정된 권한 부여 유형에 적용되는 리소스 값입니다. Secrets Manager ARN 또는 CodeConnections ARN일 수 있습니다.

source/**reportBuildStatus**  <a name="cli.source.reportbuildstatus"></a>
빌드의 시작 및 완료 상태를 소스 공급자에게 보낼지 여부를 지정합니다. GitHub, GitHub Enterprise Server 또는 Bitbucket이 아닌 소스 공급자로 설정하는 경우, `invalidInputException`이 발생합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 섹션을 참조하세요.

source/**buildStatusConfig**  <a name="cli.source.buildstatusconfig"></a>
CodeBuild 빌드 프로젝트가 빌드 상태를 소스 공급자에게 보고하는 방법을 정의하는 정보를 포함합니다. 이 옵션은 소스 유형이 `GITHUB`, `GITHUB_ENTERPRISE` 또는 `BITBUCKET`인 경우에만 사용됩니다.    
source/buildStatusConfig/**context**  
Bitbucket 소스의 경우 이 파라미터는 Bitbucket 커밋 상태의 `name` 파라미터에 사용됩니다. GitHub 소스의 경우 이 파라미터는 GitHub 커밋 상태의 `context` 파라미터에 사용됩니다.  
예를 들어 CodeBuild 환경 변수를 사용하여 `context`에 빌드 번호와 webhook 트리거를 포함할 수 있습니다.  

```
AWS CodeBuild sample-project Build #$CODEBUILD_BUILD_NUMBER - $CODEBUILD_WEBHOOK_TRIGGER
```
그 결과 webhook 풀 요청 이벤트에 의해 트리거된 빌드 \$124에 대해 다음과 같은 컨텍스트가 나타납니다.  

```
AWS CodeBuild sample-project Build #24 - pr/8
```  
source/buildStatusConfig/**targetUrl**  
Bitbucket 소스의 경우 이 파라미터는 Bitbucket 커밋 상태의 `url` 파라미터에 사용됩니다. GitHub 소스의 경우 이 파라미터는 GitHub 커밋 상태의 `target_url` 파라미터에 사용됩니다.  
예를 들어 `targetUrl`를 `https://aws.amazon.com/codebuild/<path to build>`로 설정하면 커밋 상태가 이 URL에 연결됩니다.  
CodeBuild 환경 변수를 `targetUrl`에 포함하여 URL에 추가 정보를 추가할 수도 있습니다. 예를 들어 URL에 빌드 리전을 영역을 추가하려면 다음과 같이 `targetUrl`을 설정합니다.  

```
"targetUrl": "https://aws.amazon.com/codebuild/<path to build>?region=$AWS_REGION"
```
빌드 리전이 `us-east-2`이면 다음과 같이 확장됩니다.  

```
https://aws.amazon.com/codebuild/<path to build>?region=us-east-2
```

source/**gitSubmodulesConfig**  <a name="cli.source.gitsubmodulesconfig"></a>
선택 사항입니다. Git 하위 모듈 구성에 대한 정보입니다. CodeCommit, GitHub, GitHub Enterprise Server 및 Bitbucket에서만 사용됩니다.    
source/gitSubmodulesConfig/**fetchSubmodules**  
리포지토리에 Git 하위 모듈을 포함하려면 `fetchSubmodules`를 `true`로 설정합니다. 포함된 Git 하위 모듈은 HTTPS로 구성해야 합니다.

source/**InsecureSsl**  <a name="cli.source.insecuressl"></a>
선택 사항입니다. GitHub Enterprise Server에서만 사용됩니다. GitHub Enterprise Server 프로젝트 리포지토리에 연결되어 있는 동안 TLS 경고를 무시하려면 이 값을 `true`로 설정합니다. 기본값은 `false`입니다. `InsecureSsl`은 테스트 용도로만 사용해야 합니다. 프로덕션 환경에 사용하면 안 됩니다.

source/**sourceIdentifier**  <a name="cli.source.sourceidentifier"></a>
프로젝트 소스의 사용자 정의 식별자입니다. 기본 소스의 경우 선택 사항입니다. 보조 소스에 필요합니다.

#### **secondarySources**
<a name="cli.secondarysources"></a>

선택 사항입니다. 빌드 프로젝트의 보조 소스에 대한 정보가 들어 있는 [ProjectSource](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html) 객체의 배열입니다. 보조 소스는 12개까지 추가할 수 있습니다. `secondarySources` 객체는 [**소스**](#cli.source) 객체에서 사용하는 것과 동일한 속성을 사용합니다. 보조 소스 객체에는 `sourceIdentifier`가 필요합니다.

#### **secondarySourceVersions**
<a name="cli.secondarysourceversions"></a>

선택 사항입니다. [ProjectSourceVersion](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSourceVersion.html) 객체의 배열입니다. 빌드 레벨에서 `secondarySourceVersions`이 지정되어 있으면 그 버전이 이 버전보다 우선합니다.

#### **sourceVersion**
<a name="cli.sourceversion"></a>

선택 사항입니다. 이 프로젝트에 대해 빌드할 빌드 입력의 버전입니다. 지정하지 않으면 최신 버전이 사용됩니다. 지정하면 다음 중 하나여야 합니다.
+ CodeCommit의 경우 사용할 커밋 ID, 분기 또는 Git 태그입니다.
+ GitHub의 경우, 빌드하려는 소스 코드의 버전에 해당하는 커밋 ID, 풀 요청 ID, 분기 이름 또는 태그 이름입니다. 풀 요청 ID가 지정된 경우 `pr/pull-request-ID` 형식을 사용해야 합니다(예: `pr/25`). 분기 이름이 지정되어 있으면 분기의 HEAD 커밋 ID가 사용됩니다. 지정되지 않은 경우 기본 분기의 HEAD 커밋 ID가 사용됩니다.
+ GitLab의 경우 커밋 ID, pull 요청 ID, 분기 이름, 태그 이름 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.
+ Bitbucket의 경우, 빌드하려는 소스 코드의 버전에 해당하는 커밋 ID, 분기 이름 또는 태그 이름입니다. 분기 이름이 지정되어 있으면 분기의 HEAD 커밋 ID가 사용됩니다. 지정되지 않은 경우 기본 분기의 HEAD 커밋 ID가 사용됩니다.
+ Amazon S3의 경우 사용할 빌드 입력 ZIP 파일을 나타내는 객체의 버전 ID입니다.

빌드 수준에서 `sourceVersion`이 지정되어 있으면 (프로젝트 수준에서) 그 버전이 이 `sourceVersion`보다 우선합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.

#### **artifacts**
<a name="cli.artifacts"></a>

필수 사항입니다. 이 빌드 프로젝트의 출력 아티팩트 설정에 대한 정보가 들어 있는 [ProjectArtifacts](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectArtifacts.html) 객체입니다. `artifacts` 객체를 추가한 후에는 [secondaryArtifacts](#cli.secondaryartifacts)를 사용해 아티팩트를 최대 12개까지 더 추가할 수 있습니다. 이러한 설정에는 다음이 포함됩니다.

artifacts/**type**  <a name="cli.artifacts.type"></a>
필수 사항입니다. 빌드 출력 결과물의 유형입니다. 유효한 값은 다음과 같습니다.  
+ `CODEPIPELINE`
+ `NO_ARTIFACTS`
+ `S3`

artifacts/**location**  <a name="cli.artifacts.location"></a>
`S3` 아티팩트 유형에만 사용됩니다. 다른 아티팩트 유형에는 사용되지 않습니다.  
사전 요구 사항에서 생성했거나 식별한 출력 버킷의 이름입니다.

artifacts/**path**  <a name="cli.artifacts.path"></a>
`S3` 아티팩트 유형에만 사용됩니다. 다른 아티팩트 유형에는 사용되지 않습니다.  
ZIP 파일 또는 폴더를 배치할 출력 버킷의 경로입니다. `path`의 값을 지정하지 않으면 CodeBuild가 `namespaceType`(지정된 경우) 및 `name`을 사용하여 빌드 출력 ZIP 파일이나 폴더의 경로 및 이름을 결정합니다. 예를 들어 `path`에 대해 `MyPath`, `name`에 대해 `MyArtifact.zip`을 를 지정하면 경로와 이름은 `MyPath/MyArtifact.zip`이 됩니다.

artifacts/**namespaceType**  <a name="cli.artifacts.namespacetype"></a>
`S3` 아티팩트 유형에만 사용됩니다. 다른 아티팩트 유형에는 사용되지 않습니다.  
빌드 출력 ZIP 파일 또는 폴더의 네임스페이스입니다. 유효한 값에는 `BUILD_ID` 및 `NONE`(이)가 있습니다. 빌드 출력 ZIP 파일 또는 폴더의 경로에 빌드 ID를 삽입하려면 `BUILD_ID`를 사용하고 그렇지 않은 경우 `NONE`을 사용합니다. `namespaceType`의 값을 지정하지 않으면 CodeBuild가 `path`(지정된 경우) 및 `name`을 사용하여 빌드 출력 ZIP 파일이나 폴더의 경로 및 이름을 결정합니다. 예를 들어 `path`에 대해 `MyPath`, `namespaceType`에 대해 `BUILD_ID`, `name`에 대해 `MyArtifact.zip`을 지정하면 경로와 이름은 `MyPath/build-ID/MyArtifact.zip`이 됩니다.

artifacts/**name**  <a name="cli.artifacts.name"></a>
`S3` 아티팩트 유형에만 사용됩니다. 다른 아티팩트 유형에는 사용되지 않습니다.  
`location` 안에 있는 빌드 출력 ZIP 파일 또는 폴더의 경로 및 이름입니다. 예를 들어 `path`에 대해 `MyPath`, `name`에 대해 `MyArtifact.zip`을 를 지정하면 경로와 이름은 `MyPath/MyArtifact.zip`이 됩니다.

artifacts/**overrideArtifactName**  <a name="cli.artifacts.overrideartifactname"></a>
S3 아티팩트 유형에만 사용됩니다. 다른 아티팩트 유형에는 사용되지 않습니다.  
선택 사항입니다. `true`로 설정할 경우 buildspec 파일의 `artifacts` 블록에서 지정한 이름이 `name`을 재정의합니다. 자세한 내용은 [CodeBuild의 빌드 사양 참조](build-spec-ref.md) 섹션을 참조하세요.

artifacts/**packaging**  <a name="cli.artifacts.packaging"></a>
`S3` 아티팩트 유형에만 사용됩니다. 다른 아티팩트 유형에는 사용되지 않습니다.  
선택 사항입니다. 아티팩트를 패키징하는 방법을 지정합니다. 허용되는 값:    
NONE  
빌드 아티팩트가 포함된 폴더를 생성합니다. 이것이 기본값입니다.  
ZIP  
빌드 아티팩트가 포함된 ZIP 파일을 생성합니다.

#### secondaryArtifacts
<a name="cli.secondaryartifacts"></a>

선택 사항입니다. 빌드 프로젝트의 보조 아티팩트 설정에 대한 정보가 들어 있는 [ProjectArtifacts](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectArtifacts.html) 객체의 배열입니다. 보조 아티팩트는 최대 12개까지 추가할 수 있습니다. `secondaryArtifacts`는 [**artifacts**](#cli.artifacts) 객체에서 사용하는 것과 동일한 수의 설정을 사용합니다.

#### cache
<a name="cli.cache"></a>

필수 사항입니다. 이 빌드 프로젝트의 캐시 설정에 대한 정보가 들어 있는 [ProjectCache](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectCache.html) 객체입니다. 자세한 내용은 [캐시 빌드](build-caching.md) 섹션을 참조하세요.

#### 환경
<a name="cli.environment"></a>

필수 사항입니다. 이 프로젝트의 빌드 환경 설정에 대한 정보가 들어 있는 [ProjectEnvironment](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectEnvironment.html) 객체입니다. 이러한 설정은 다음과 같습니다.

environment/**type**  <a name="cli.environment.type"></a>
필수 사항입니다. 빌드 환경의 유형입니다. 자세한 내용은 *CodeBuild API 참조*의 [유형](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectEnvironment.html#CodeBuild-Type-ProjectEnvironment-type)을 참조하세요.

environment/**image**  <a name="cli.environment.image"></a>
필수 사항입니다. 이 빌드 환경에서 사용하는 도커 이미지 식별자입니다. 일반적으로 이 식별자는 *image-name*:*tag*로 표현됩니다. 예를 들어 CodeBuild가 도커 이미지를 관리하는 데 사용하는 Docker 리포지토리에서 이 값은 `aws/codebuild/standard:5.0`이 될 수 있습니다. Docker Hub에서는 `maven:3.3.9-jdk-8`입니다. Amazon ECR에서는 `account-id.dkr.ecr.region-id.amazonaws.com/your-Amazon-ECR-repo-name:tag`입니다. 자세한 내용은 [CodeBuild가 제공하는 도커 이미지](build-env-ref-available.md) 섹션을 참조하세요.

environment/**computeType**  <a name="cli.environment.computetype"></a>
필수 사항입니다. 이 빌드 환경에서 사용하는 컴퓨팅 리소스를 지정합니다. 자세한 내용은 *CodeBuild API 참조*의 [computeType](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectEnvironment.html#CodeBuild-Type-ProjectEnvironment-computeType)을 참조하세요.

environment/**certificate**  <a name="cli.environment.certificate"></a>
선택 사항입니다. PEM 인코딩된 인증서를 포함하는 Amazon S3 버킷, 경로 접두사 및 객체 키의 ARN입니다. 객체 키는 단지 .pem 파일일 수도 있고 PEM 인코딩된 인증서를 포함하는 .zip 파일일 수도 있습니다. 예를 들어 Amazon S3 버킷 이름이 `<my-bucket>`이고 경로 접두사는 `<cert>`이고 객체 키 이름이 `<certificate.pem>`인 경우 `certificate`에 허용되는 형식은 `<my-bucket/cert/certificate.pem>` 또는 `arn:aws:s3:::<my-bucket/cert/certificate.pem>`입니다.

environment/**environmentVariables**  <a name="cli.environment.environmentvariables"></a>
선택 사항입니다. 이 빌드 환경에 지정하려는 환경 변수를 포함하는 [EnvironmentVariable](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_EnvironmentVariable.html) 객체의 배열입니다. 각 환경 변수는 `name`, `value`, `type`의 `name`, `value`, `type`을 포함하는 객체로 표현됩니다.  
콘솔 및 AWS CLI 사용자는 환경 변수를 확인할 수 있습니다. 환경 변수의 가시성에 대한 문제가 없으면 `name` 및 `value`를 설정하고 `type`을 `PLAINTEXT`로 설정합니다.  
AWS 액세스 키 ID, AWS 비밀 액세스 키 또는 암호와 같은 중요한 값을 가진 환경 변수를 Amazon EC2 Systems Manager Parameter Store 또는 AWS Secrets Manager에 파라미터로 저장하는 것이 좋습니다. `name`의 저장된 파라미터의 경우 CodeBuild가 참조할 식별자를 설정합니다.  
Amazon EC2 Systems Manager Parameter Store를 사용하는 경우, `value`에 대해 파라미터 이름을 Parameter Store에 저장된 것으로 설정합니다. `type`를 `PARAMETER_STORE`으로 설정합니다. 이름이 `/CodeBuild/dockerLoginPassword`인 파라미터를 예제로 사용하여 `name`을 `LOGIN_PASSWORD`로 설정합니다. `value`을 `/CodeBuild/dockerLoginPassword`으로 설정합니다. `type`를 `PARAMETER_STORE`로 설정합니다.  
Amazon EC2 Systems Manager Parameter Store를 사용하는 경우 `/CodeBuild/`로 시작하는 파라미터 이름(예: `/CodeBuild/dockerLoginPassword`)으로 파라미터를 저장하는 것이 좋습니다. CodeBuild 콘솔을 사용하여 Amazon EC2 Systems Manager에서 파라미터를 생성할 수 있습니다. **파라미터 생성**을 선택하고 대화 상자에 표시되는 지시에 따릅니다. 대화 상자의 **KMS 키**에 해당 계정의 AWS KMS 키에 대한 ARN을 지정할 수 있습니다. Amazon EC2 Systems Manager는 이 키를 사용하여 저장 시 파라미터의 값을 암호화하고 검색 시 암호를 해독합니다. CodeBuild 콘솔을 사용하여 파라미터를 생성하는 경우 콘솔은 이름이 `/CodeBuild/`인 파라미터가 저장되면 시작합니다. 자세한 내용은 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)을 참조하세요.**  
빌드 프로젝트가 Amazon EC2 Systems Manager Parameter Store에 저장된 파라미터를 참조하는 경우 해당 빌드 프로젝트의 서비스 역할은 `ssm:GetParameters` 작업을 허용해야 합니다. 앞에서 **새 서비스 역할**을 선택한 경우에는 CodeBuild는 빌드 프로젝트의 기본 서비스 역할에 이 작업을 포함합니다. **Existing service role(기존 서비스 역할)**을 선택한 경우에는 이 작업을 서비스 역할에 별도로 포함해야 합니다.  
빌드 프로젝트가 `/CodeBuild/`로 시작되지 않는 파라미터 이름으로 Amazon EC2 Systems Manager Parameter Store에 저장된 파라미터를 참조하는 경우 **새 서비스 역할**을 선택하면 `/CodeBuild/`로 시작하지 않는 파라미터 이름에 액세스할 수 있도록 해당 서비스 역할을 업데이트해야 합니다. 이는 서비스 역할이 `/CodeBuild/`로 시작하는 파라미터 이름에만 액세스할 수 있기 때문입니다.  
**새 서비스 역할**을 선택하면 Amazon EC2 Systems Manager Parameter Store에 있는 `/CodeBuild/` 네임스페이스의 모든 파라미터를 해독할 권한이 서비스 역할에 포함됩니다.  
사용자가 설정한 환경 변수는 기존 환경 변수를 대체합니다. 예를 들어 도커 이미지에 값이 `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_`로 시작하는 이름으로 환경 변수를 설정하지 마십시오. 이 접두사는 내부 전용으로 예약되어 있습니다.  
여러 위치에서 동일한 이름의 환경 변수가 정의되는 경우, 다음과 같이 값이 결정됩니다.  
+ 시작 빌드 작업 호출의 값이 가장 높은 우선 순위를 갖습니다.
+ 빌드 프로젝트 정의의 값이 다음 우선 순위를 갖습니다.
+ buildspec 선언의 값이 가장 낮은 우선 순위를 갖습니다.
Secrets Manager를 `value` 사용하는 경우 파라미터 이름을 Secrets Manager에 저장된 항목으로 설정합니다. `type`를 `SECRETS_MANAGER`으로 설정합니다. 이름이 `/CodeBuild/dockerLoginPassword`인 보안 암호를 예제로 사용하여 `name`을 `LOGIN_PASSWORD`로 설정합니다. `value`을 `/CodeBuild/dockerLoginPassword`으로 설정합니다. `type`를 `SECRETS_MANAGER`로 설정합니다.  
Secrets Manager를 사용하는 경우 이름이 `/CodeBuild/`로 시작하는 암호를 저장하는 것이 좋습니다(예: `/CodeBuild/dockerLoginPassword`). 자세한 내용은 AWS Secrets Manager 사용 설명서의 [AWS Secrets Manager이란?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 섹션을 참조하세요.**  
빌드 프로젝트가 Secrets Manager에 저장된 암호를 참조하는 경우 해당 빌드 프로젝트의 서비스 역할은 `secretsmanager:GetSecretValue` 작업을 허용해야 합니다. 앞에서 **새 서비스 역할**을 선택한 경우에는 CodeBuild는 빌드 프로젝트의 기본 서비스 역할에 이 작업을 포함합니다. **Existing service role(기존 서비스 역할)**을 선택한 경우에는 이 작업을 서비스 역할에 별도로 포함해야 합니다.  
빌드 프로젝트가 `/CodeBuild/`로 시작되지 않는 보안 암호 이름으로 Secrets Manager에 저장된 암호를 참조하는 경우 **새 서비스 역할**을 선택하면 `/CodeBuild/`로 시작하지 않는 보안 암호 이름에 액세스할 수 있도록 해당 서비스 역할을 업데이트해야 합니다. 이는 서비스 역할이 `/CodeBuild/`로 시작하는 암호 이름에만 액세스할 수 있기 때문입니다.  
**새 서비스 역할**을 선택하면 에 있는 `/CodeBuild/` 네임스페이스의 모든 암호를 해독할 권한이 서비스 역할에 포함됩니다.

environment/**registryCredential**  <a name="cli.environment.registrycredential"></a>
선택 사항입니다. 프라이빗 Docker 레지스트리에 대한 액세스를 제공하는 보안 인증을 지정하는 [RegistryCredential](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_RegistryCredential.html) 객체입니다.    
environment/registryCredential/**credential**  
AWS Managed Services를 사용하여 생성한 보안 인증의 ARN 또는 이름을 지정합니다. 현재 리전에 있는 자격 증명의 이름만 사용할 수 있습니다.  
environment/registryCredential/**credentialProvider**  
유일한 유효 값은 `SECRETS_MANAGER`입니다.
이를 설정할 경우 다음과 같이 해야 합니다.  
+ `imagePullCredentials`/를 로 설정해야 합니다.`SERVICE_ROLE`
+ 이 이미지는 큐레이트된 이미지 또는 Amazon ECR 이미지일 수 없습니다.

environment/**imagePullCredentialsType**  <a name="cli.environment.imagepullcredentialstype"></a>
선택 사항입니다. CodeBuild가 빌드에 이미지를 가져올 때 사용하는 보안 인증 유형입니다. 두 가지 값을 사용할 수 있습니다.    
CODEBUILD  
`CODEBUILD`는 CodeBuild가 자체 보안 인증을 사용하도록 지정합니다. CodeBuild 서비스 보안 주체를 신뢰하려면 Amazon ECR 리포지토리 정책을 편집해야 합니다.  
SERVICE\$1ROLE  
CodeBuild가 해당 빌드 프로젝트의 서비스 역할을 사용하도록 지정합니다.
교차 계정 또는 프라이빗 레지스트리 이미지를 사용할 경우 `SERVICE_ROLE` 자격 증명을 사용해야 합니다. CodeBuild 큐레이트 이미지를 사용할 경우 `CODEBUILD` 보안 인증을 사용해야 합니다.

environment/**privilegedMode**  <a name="cli.environment.privilegedmode"></a>
이 빌드 프로젝트를 사용하여 도커 이미지를 빌드하려는 경우에만 `true`로 설정합니다. 그렇지 않으면 Docker 데몬과 상호 작용을 시도하는 모든 연결된 빌드가 실패합니다. 또한 빌드가 상호 작용할 수 있도록 Docker 데몬을 시작해야 합니다. 이를 수행하는 한 가지 방법은 다음 빌드 명령을 실행하여 buildspec 파일의 `install` 단계에서 Docker 데몬을 초기화하는 것입니다. 지정한 빌드 환경 이미지가 Docker 지원을 통해 CodeBuild에서 제공하지 않은 경우 이 명령을 실행하지 마세요.  
기본적으로 비 VPC 빌드에는 Docker 데몬이 활성화됩니다. VPC 빌드에 Docker 컨테이너를 사용하려면 Docker Docs 웹 사이트의 [런타임 권한 및 Linux 기능](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)을 참조하고 권한 부여 모드를 활성화합니다. 또한 Windows는 권한 모드를 지원하지 않습니다.

```
- nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 &
- timeout 15 sh -c "until docker info; do echo .; sleep 1; done"
```

#### serviceRole
<a name="cli.servicerole"></a>

필수 사항입니다. CodeBuild가 사용자 대신 서비스와 상호 작용하기 위해 사용하는 서비스 역할의 ARN입니다(예: `arn:aws:iam::account-id:role/role-name`).

#### autoRetryLimit
<a name="cli.autoretrylimit"></a>

선택 사항입니다. 빌드 실패 후 추가 자동 재시도 횟수입니다. 예를 들어 자동 재시도 제한이 2로 설정된 경우 CodeBuild는 `RetryBuild` API를 호출하여 빌드를 추가로 최대 2회 자동 재시도합니다.

#### timeoutInMinutes
<a name="cli.timeoutinminutes"></a>

선택 사항입니다. 빌드가 완료되지 않는 경우 CodeBuild가 해당 빌드를 중지하는 시간(5분에서 2160분(36시간) 사이)입니다. 지정하지 않을 경우 기본값인 60을 사용합니다. 시간 제한으로 인해 CodeBuild가 빌드를 중지했는지 및 중지한 시간을 확인하려면 `batch-get-builds` 명령을 실행합니다. 빌드가 중지되었는지 확인하려면 출력에서 `buildStatus`의 `FAILED` 값을 살펴봅니다. 빌드가 시간 초과된 시간을 확인하려면 출력에서 `endTime`의 `phaseStatus`와 연결된 `TIMED_OUT` 값을 살펴봅니다.

#### queuedTimeoutInMinutes
<a name="cli.queuedtimeoutinminutes"></a>

선택 사항입니다. 빌드가 완료되지 않는 경우 CodeBuild가 해당 빌드를 중지하는 시간(5분에서 480분(8시간) 사이)입니다. 지정하지 않을 경우 기본값인 60을 사용합니다.

#### encryptionKey
<a name="cli.encryptionkey"></a>

선택 사항입니다. CodeBuild에서 빌드 출력을 암호화하는 데 사용하는 AWS KMS key의 별칭 또는 ARN입니다. 별칭을 지정하는 경우 `arn:aws:kms:region-ID:account-ID:key/key-ID` 형식을 사용하고, 별칭이 있는 경우 `alias/key-alias` 형식을 사용합니다. 지정하지 않으면 Amazon S3의 AWS 관리형 KMS 키가 사용됩니다.

#### 태그
<a name="cli.tags"></a>

선택 사항입니다. 이 빌드 프로젝트와 연결할 태그를 제공하는 [Tag](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Tag.html) 객체 배열입니다. 최대 50개의 태그를 지정할 수 있습니다. 이러한 태그는 CodeBuild 빌드 프로젝트 태그를 지원하는 AWS 서비스가 사용할 수 있습니다. 각 태그는 `key`와 `value`가 있는 객체로 표현됩니다.

#### vpcConfig
<a name="cli.vpcconfig"></a>

선택 사항입니다. 프로젝트의 VPC 구성에 대한 정보가 들어 있는 [VpcConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_VpcConfig.html) 객체입니다. 자세한 내용은 [Amazon Virtual Private Cloud AWS CodeBuild 와 함께 사용](vpc-support.md) 섹션을 참조하세요.

이러한 속성은 다음과 같습니다.

vpcId  
필수 사항입니다. CodeBuild가 사용하는 VPC ID입니다. 리전의 모든 VPC ID 목록을 가져오려면 다음 명령을 실행합니다.  

```
aws ec2 describe-vpcs --region <region-ID>
```

subnets  
필수 사항입니다. CodeBuild에서 사용되는 리소스가 포함된 서브넷 ID의 배열입니다. 이 ID를 얻으려면 다음 명령을 실행합니다.  

```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=<vpc-id>" --region <region-ID>
```

securityGroupIds  
필수 사항입니다. CodeBuild가 VPC의 리소스에 대한 액세스를 허용하기 위해 사용하는 보안 그룹 ID 배열입니다. 이 ID를 얻으려면 다음 명령을 실행합니다.  

```
aws ec2 describe-security-groups --filters "Name=vpc-id,Values=<vpc-id>" --<region-ID>
```

#### badgeEnabled
<a name="cli.badgeenabled"></a>

선택 사항입니다. CodeBuild 프로젝트에 빌드 배지를 포함할지 여부를 지정합니다. 빌드 배지를 활성화하려면 `true`로 설정하고, 그렇지 않으면 `false`로 설정합니다. 자세한 내용은 [CodeBuild의 빌드 배지 샘플](sample-build-badges.md) 섹션을 참조하세요.

#### logsConfig
<a name="cli.logsconfig"></a>

이 빌드의 로그가 있는 위치에 대한 정보가 들어 있는 [LogsConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_LogsConfig.html) 객체입니다.

logsConfig/**cloudWatchLogs**  <a name="cli.logsconfig.cloudwatchlogs"></a>
로그를 CloudWatch Logs로 푸시하는 것과 관련된 정보가 들어 있는 [CloudWatchLogsConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_CloudWatchLogsConfig.html) 객체입니다.

logsConfig/**s3Logs**  <a name="cli.logsconfig.s3logs"></a>
로그를 Amazon S3로 푸시하는 방법에 대한 정보가 들어 있는 [S3LogsConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_S3LogsConfig.html) 객체입니다.

#### fileSystemLocations
<a name="cli.filesystemlocations"></a>

선택 사항입니다. Amazon EFS 구성에 대한 정보가 들어 있는 [ProjectFileSystemsLocation](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectFileSystemLocation.html) 객체의 배열입니다.

#### buildBatchConfig
<a name="cli.buildbatchconfig"></a>

선택 사항입니다. `buildBatchConfig` 객체는 프로젝트에 대한 배치 빌드 구성 정보를 포함하는 [ProjectBuildBatchConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectBuildBatchConfig.html) 구조입니다.

buildBatchConfig/**serviceRole**  
배치 빌드 프로젝트에 대한 서비스 역할 ARN입니다.

buildBatchConfig/**combineArtifacts**  
배치 빌드의 빌드 아티팩트를 단일 아티팩트 위치로 결합할지 여부를 지정하는 부울 값입니다.

buildBatchConfig/restrictions/**maximumBuildsAllowed**  
허용되는 최대 빌드 수입니다.

buildBatchConfig/restrictions/**computeTypesAllowed**  
배치 빌드에 허용되는 컴퓨팅 유형을 지정하는 문자열 배열입니다. 이러한 값은 [빌드 환경 컴퓨팅 유형](https://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref-compute-types.html)를 참조하세요.

buildBatchConfig/restrictions/**fleetsAllowed**  
배치 빌드에 허용되는 플릿을 지정하는 문자열 배열입니다. 자세한 내용은 [예약 용량 플릿에서 빌드 실행](https://docs.aws.amazon.com/codebuild/latest/userguide/fleets.html)을 참조하세요.

buildBatchConfig/**timeoutInMinutes**  
배치 빌드를 완료해야 하는 최대 시간(분)입니다.

buildBatchConfig/**batchReportMode**   
배치 빌드를 위해 빌드 상태 보고서를 소스 제공자에게 보내는 방법을 지정합니다. 유효한 값으로는 다음이 포함됩니다.    
`REPORT_AGGREGATED_BATCH`  
(기본값) 모든 빌드 상태를 단일 상태 보고서로 집계합니다.  
`REPORT_INDIVIDUAL_BUILDS`  
각 개별 빌드에 대해 별도의 상태 보고서를 보냅니다.

#### concurrentBuildLimit
<a name="cli.concurrentbuildlimit"></a>

이 프로젝트에 허용된 최대 동시 실행 빌드 수입니다.

현재 빌드 수가 이 한도 이하인 경우에만 새 빌드가 시작됩니다. 현재 빌드 수가 이 한도에 도달하면 새 빌드가 제한되고 실행되지 않습니다.

### 프로젝트 생성
<a name="cp-cli-create-project"></a>

프로젝트를 생성하려면 JSON 파일을 전달하여 **[https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html)** 명령을 다시 실행합니다.

```
aws codebuild create-project --cli-input-json file://<json-file>
```

성공하면 [Project](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Project.html) 객체의 JSON 표현이 콘솔 출력에 나타납니다. 이 데이터의 예는 [CreateProject 응답 구문](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_CreateProject.html#API_CreateProject_ResponseSyntax)을 참조하세요.

빌드 프로젝트 이름을 제외한 모든 빌드 프로젝트 설정은 나중에 변경할 수 있습니다. 자세한 내용은 [빌드 프로젝트 설정 변경(AWS CLI)](change-project.md#change-project-cli) 섹션을 참조하세요.

빌드 실행을 시작하려면 [빌드 실행(AWS CLI)](run-build-cli.md) 단원을 참조하십시오.

소스 코드가 GitHub 리포지토리에 저장되고 코드 변경이 리포지토리로 푸시될 때마다 CodeBuild가 자동으로 소스 코드를 다시 빌드하게 하려면 [빌드 실행 자동 시작(AWS CLI)](run-build-cli-auto-start.md) 섹션을 참조하세요.

## 빌드 프로젝트 생성(AWS SDK)
<a name="create-project-sdks"></a>

AWS CodeBuild를 AWS SDK와 함께 사용하는 방법에 대한 자세한 정보는 [AWS SDKs 및 도구 참조](sdk-ref.md) 단원을 참조하십시오.

## 빌드 프로젝트 생성(CloudFormation)
<a name="create-project-cloud-formation"></a>

CloudFormation에서 AWS CodeBuild를 사용하는 방법에 대한 자세한 내용은 AWS CloudFormation 사용 설명서의 [CodeBuild용 CloudFormation 템플릿](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codebuild-project.html)을 참조하세요.**

# 알림 규칙 생성
<a name="notification-rule-create"></a>

알림 규칙을 사용하여 빌드 성공 및 실패와 같은 중요한 변경 사항이 발생할 경우 사용자에게 알릴 수 있습니다. 알림 규칙은 알림을 보내는 데 사용되는 이벤트와 Amazon SNS 주제를 모두 지정합니다. 자세한 내용은 [알림이란 무엇입니까?](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/welcome.html)를 참조하세요.



콘솔 또는를 사용하여 알림 규칙을 AWS CLI 생성할 수 있습니다 AWS CodeBuild.<a name="notification-rule-create-console"></a>

# 알림 규칙을 생성하려면 (콘솔)
<a name="notification-rule-create-console"></a>

1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/) CodeBuild 콘솔을 엽니다.

1. **빌드**, **빌드 프로젝트**를 차례로 선택한 다음 알림을 추가할 빌드 프로젝트를 선택합니다.

1. 빌드 프로젝트 페이지에서 **알림**을 선택하고 **Create notification rule(알림 규칙 생성)**을 선택합니다. 빌드 프로젝트의 **설정** 페이지로 이동하여 **Create notification rule(알림 규칙 생성)**를 선택할 수도 있습니다.

1. **알림 이름**에 규칙에 대한 이름을 입력합니다.

1. 알림에 포함된 Amazon EventBridge에 제공된 정보만 원하는 경우 **세부 정보 유형**에서 **기본**을 선택합니다. Amazon EventBridge에 제공된 정보와 CodeBuild 또는 알림 관리자에서 제공할 수 있는 정보를 포함하려는 경우 **전체**를 선택합니다.

   자세한 내용은 [알림 내용 및 보안 이해](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/security.html#security-notifications)를 참조하세요.

1.  **알림을 트리거하는 이벤트**에서 알림을 보내고자 하는 이벤트를 선택합니다. 자세한 내용은 [빌드 프로젝트의 알림 규칙 이벤트](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/concepts.html#events-ref-buildproject)를 참조하십시오.

1. **대상**에서 다음 중 하나를 수행합니다.
   + 알림과 함께 사용할 리소스를 이미 구성한 경우 **대상 유형 선택**에서 **채팅 애플리케이션의 Amazon Q Developer(Slack)** 또는 **SNS 주제**를 선택합니다. **대상 선택**에서 클라이언트의 이름(채팅 애플리케이션에서 Amazon Q Developer로 구성된 Slack 클라이언트의 경우) 또는 Amazon SNS 주제의 Amazon 리소스 이름(ARN)(알림에 필요한 정책으로 이미 구성된 Amazon SNS 주제의 경우)을 선택합니다.
   + 알림과 함께 사용할 리소스를 구성하지 않은 경우 **대상 생성**을 선택한 다음 **SNS 주제**를 선택합니다. **codestar-notifications-** 뒤에 주제 이름을 입력한 다음 **생성**을 선택합니다.
**참고**  
알림 규칙을 만드는 과정에서 Amazon SNS 주제를 생성하면 알림 기능이 주제에 이벤트를 게시할 수 있도록 허용하는 정책이 적용됩니다. 알림 규칙에 대해 생성된 주제를 사용하면 이 리소스에 대한 알림을 받기를 원하는 사용자만 구독할 수 있습니다.
알림 규칙을 만드는 중에는 채팅 애플리케이션 클라이언트에 Amazon Q Developer를 만들 수 없습니다. 채팅 애플리케이션에서 Amazon Q Developer(Slack)를 선택하면 채팅 애플리케이션에서 Amazon Q Developer의 클라이언트를 구성하라는 버튼이 표시됩니다. 이 옵션을 선택하면 채팅 애플리케이션 콘솔에 Amazon Q Developer가 열립니다. 자세한 내용은 [채팅 애플리케이션에서 알림과 Amazon Q Developer 간의 통합 구성](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/notifications-chatbot.html)을 참조하세요.
기존 Amazon SNS 주제를 대상으로 사용하려면 해당 주제에 대해 존재할 수 있는 다른 정책 외에 AWS CodeStar Notifications에 필요한 정책을 추가해야 합니다. 자세한 내용은 [알림에 대한 Amazon SNS 주제 구성](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/set-up-sns.html)과 [알림 내용 및 보안 이해](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/security.html#security-notifications)를 참조하세요.

1. 규칙 생성을 완료하려면 **제출**을 선택합니다.

1. 사용자가 알림을 받으려면 먼저 규칙에 대한 Amazon SNS 주제를 사용자가 구독하도록 해야 합니다. 자세한 내용은 [대상인 Amazon SNS 주제에 사용자 구독](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/subscribe-users-sns.html)을 참조하세요. 채팅 애플리케이션에서 알림과 Amazon Q Developer 간의 통합을 설정하여 Amazon Chime 채팅룸에 알림을 보낼 수도 있습니다. 자세한 내용은 [채팅 애플리케이션에서 알림과 Amazon Q Developer 간의 통합 구성](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/notifications-chatbot.html)을 참조하세요.<a name="notification-rule-create-cli"></a>

# 알림 규칙을 생성하려면(AWS CLI)
<a name="notification-rule-create-cli"></a>

1. 터미널 또는 명령 프롬프트에서 **create-notification rule** 명령을 실행하여 JSON 스켈레톤을 생성합니다.

   ```
   aws codestarnotifications create-notification-rule --generate-cli-skeleton > rule.json
   ```

   원하는 대로 파일 이름을 지정할 수 있습니다. 이 예에서는 *rule.json*으로 파일 이름을 지정합니다.

1. 일반 텍스트 편집기에서 JSON 파일을 열고 규칙에 대해 원하는 리소스, 이벤트 유형 및 대상을 포함하도록 편집합니다. 다음 예제는 ID가 *123456789012*인 AWS 계정의 *MyBuildProject*라는 빌드 프로젝트에 **MyNotificationRule** 대한 라는 알림 규칙을 보여줍니다. 빌드가 성공적일 때 *codestar-notifications-MyNotificationTopic*이라는 Amazon SNS 주제에 전체 세부 정보 유형과 함께 알림이 전송됩니다.

   ```
   {
       "Name": "MyNotificationRule",
       "EventTypeIds": [
           "codebuild-project-build-state-succeeded"
       ],
       "Resource": "arn:aws:codebuild:us-east-2:123456789012:MyBuildProject",
       "Targets": [
           {
               "TargetType": "SNS",
               "TargetAddress": "arn:aws:sns:us-east-2:123456789012:codestar-notifications-MyNotificationTopic"
           }
       ],
       "Status": "ENABLED",
       "DetailType": "FULL"
   }
   ```

   파일을 저장합니다.

1. 터미널 또는 명령줄에서 **create-notification-rule** 명령을 다시 실행하여 조금 전 편집한 파일을 사용해 알림 규칙을 생성합니다.

   ```
   aws codestarnotifications create-notification-rule --cli-input-json  file://rule.json
   ```

1. 성공한 경우 명령에서 다음과 유사한 알림 규칙의 ARN을 반환합니다.

   ```
   {
       "Arn": "arn:aws:codestar-notifications:us-east-1:123456789012:notificationrule/dc82df7a-EXAMPLE"
   }
   ```

# 에서 빌드 프로젝트 설정 변경 AWS CodeBuild
<a name="change-project"></a>

 AWS CodeBuild 콘솔 AWS CLI, 또는 AWS SDKs를 사용하여 빌드 프로젝트의 설정을 변경할 수 있습니다.

빌드 프로젝트에 테스트 보고를 추가하는 경우 IAM 역할에 [테스트 보고서 권한](test-permissions.md)에서 설명하는 사용 권한이 있는지 확인합니다.

**Topics**
+ [빌드 프로젝트 설정 변경(콘솔)](#change-project-console)
+ [빌드 프로젝트 설정 변경(AWS CLI)](#change-project-cli)
+ [빌드 프로젝트의 설정 변경(AWS SDKs)](#change-project-sdks)

## 빌드 프로젝트 설정 변경(콘솔)
<a name="change-project-console"></a>

빌드 프로젝트의 설정을 변경하려면 다음 절차에 수행하세요.

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.

1. 탐색 창에서 **프로젝트 빌드**를 선택합니다.

1. 다음 중 하나를 수행하세요.
   + 변경하려는 빌드 프로젝트의 링크를 선택한 다음 **Edit project(프로젝트 편집)**를 선택합니다.
   + 변경하려는 빌드 프로젝트 옆에 있는 라디오 버튼을 선택하고 **세부 정보 보기**를 선택한 후 **빌드 세부 정보**를 선택합니다.

다음 섹션을 수정할 수 있습니다.

**Topics**
+ [프로젝트 구성](#change-project-console-project-config)
+ [소스](#change-project-console-source)
+ [환경](#change-project-console-environment)
+ [Buildspec](#change-project-console-buildspec)
+ [배치 구성](#change-project-console-batch-config)
+ [아티팩트](#change-project-console-artifacts)
+ [로그](#change-project-console-logs)

### 프로젝트 구성
<a name="change-project-console-project-config"></a>

**프로젝트 구성** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

**설명**  
선택적으로 빌드 프로젝트에 대한 설명을 입력하여 다른 사용자가 이 프로젝트의 용도를 이해하도록 도울 수 있습니다.

**빌드 배지**  
프로젝트의 빌드 상태를 표시하고 삽입 가능하게 하려면 **Enable build badge(빌드 배치 활성화)**를 선택합니다. 자세한 내용은 [빌드 배지 샘플](sample-build-badges.md) 단원을 참조하십시오.  
소스 공급자가 Amazon S3인 경우 빌드 배지가 적용되지 않습니다.

**동시 빌드 제한 활성화**  
이 프로젝트의 동시 빌드 수를 제한하려면 다음 단계를 수행합니다.  

1. **이 프로젝트에서 시작할 수 있는 동시 빌드 수 제한**을 선택합니다.

1. **동시 빌드 제한**에 이 프로젝트에 허용되는 최대 동시 빌드 수를 입력합니다. 이 제한은 계정에 설정된 동시 빌드 제한보다 클 수 없습니다. 계정 제한보다 큰 숫자를 입력하려고 하면 오류 메시지가 표시됩니다.
현재 빌드 수가 이 한도 이하인 경우에만 새 빌드가 시작됩니다. 현재 빌드 수가 이 한도에 도달하면 새 빌드가 제한되고 실행되지 않습니다.

**퍼블릭 빌드 액세스 활성화**  <a name="change-project-console.public-builds"></a>
 AWS 계정에 액세스할 수 없는 사용자를 포함하여 프로젝트의 빌드 결과를 퍼블릭이 사용할 수 있도록 하려면 **퍼블릭 빌드 액세스 활성화**를 선택하고 빌드 결과를 퍼블릭으로 설정할지 확인합니다. 퍼블릭 빌드 프로젝트에는 다음과 같은 속성이 사용됩니다.    
**퍼블릭 빌드 서비스 역할**  
CodeBuild에서 새 서비스 역할을 생성하도록 하려면 **새 서비스 역할**을 선택하고, 기존 서비스 역할을 사용하려면 **기존 서비스 역할**을 선택합니다.  
퍼블릭 빌드 서비스 역할을 사용하면 CodeBuild가 프로젝트 빌드에 대한 CloudWatch Logs를 읽고 Amazon S3 아티팩트를 다운로드할 수 있습니다. 이 역할은 프로젝트의 빌드 로그와 아티팩트를 퍼블릭으로 지정하는 데 필요합니다.  
**서비스 역할**  
새 서비스 역할 또는 기존 서비스 역할의 이름을 입력합니다.
프로젝트의 빌드 결과를 프라이빗으로 설정하려면 **퍼블릭 빌드 액세스 활성화**를 선택 취소합니다.  
자세한 내용은 [퍼블릭 빌드 프로젝트 URL 가져오기](public-builds.md) 단원을 참조하십시오.  
프로젝트의 빌드 결과를 퍼블릭으로 유지할 때는 다음에 유의해야 합니다.  
+ 프로젝트가 프라이빗일 때 실행된 빌드를 포함하여 프로젝트의 모든 빌드 결과, 로그, 아티팩트는 누구나 이용할 수 있습니다.
+ 모든 빌드 로그와 아티팩트는 누구나 이용할 수 있습니다. 환경 변수, 소스 코드 및 기타 중요한 정보가 빌드 로그와 아티팩트에 출력되었을 수 있습니다. 빌드 로그에 출력되는 정보에 주의해야 합니다. 몇 가지 모범 사례는 다음과 같습니다.
  + 환경 변수에 민감한 값, 특히 AWS 액세스 키 IDs 및 보안 액세스 키를 저장하지 마십시오. Amazon EC2 Systems Manager 파라미터 스토어 또는를 사용하여 민감한 값을 저장하는 AWS Secrets Manager 것이 좋습니다.
  + webhook를 최대한 안전하게 보호하려면 [webhook 사용 모범 사례](webhooks.md#webhook-best-practices)에 따라 빌드를 트리거할 수 있는 엔터티를 제한하고, buildspec을 프로젝트 자체에 저장하지 마세요.
+ 악의적인 사용자는 퍼블릭 빌드를 사용하여 악성 아티팩트를 배포할 수 있습니다. 프로젝트 관리자는 모든 풀 요청을 검토하여 풀 요청이 합법적인 변경인지 확인하는 것이 좋습니다. 또한 체크섬으로 모든 아티팩트의 유효성을 검사하여 올바른 아티팩트가 다운로드되고 있는지 확인하는 것이 좋습니다.

**추가 정보**  
**태그**에 지원 AWS 서비스에서 사용할 태그의 이름과 값을 입력합니다. [**Add row**]를 사용하여 태그를 추가합니다. 최대 50개의 태그를 추가할 수 있습니다.

### 소스
<a name="change-project-console-source"></a>

**소스** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

**소스 공급자**  
소스 코드 공급자 유형을 선택합니다. 다음 목록을 사용하여 소스 공급자에 알맞은 유형을 선택합니다.  
CodeBuild에서는 Bitbucket Server를 지원하지 않습니다.

------
#### [ Amazon S3 ]

 **버킷**   
소스 코드가 포함된 입력 버킷의 이름을 선택합니다.

 **S3 객체 키 또는 S3 폴더**   
소스 코드가 포함된 ZIP 파일의 이름 또는 폴더 경로를 입력합니다. S3 버킷의 모든 항목을 다운로드하려면 슬래시(/)를 입력합니다.

 **소스 버전**   
입력 파일의 빌드를 나타내는 객체의 버전 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 단원을 참조하십시오.

------
#### [ CodeCommit ]

 **리포지토리**   
사용할 리포지토리를 선택합니다.

**참조 유형**  
**분기**, **Git 태그** 또는 **커밋 ID**를 선택하여 소스 코드 버전을 지정합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 단원을 참조하십시오.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
이력이 지정된 커밋 수로 잘린 부분 복제를 생성하려면 선택합니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

------
#### [ Bitbucket ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections**, **OAuth**, **앱 암호** 또는 **개인 액세스 토큰**을 선택하여 CodeBuild에 연결합니다.

 **Connection**   
Bitbucket 연결 또는 Secrets Manager 암호를 선택하여 지정된 연결 유형을 통해 연결합니다.

 **리포지토리**   
**내 Bitbucket 계정의 리포지토리** 또는 **퍼블릭 리포지토리**를 선택하고 리포지토리 URL을 입력합니다.

 **소스 버전**   
분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 단원을 참조하십시오.  
**상태 컨텍스트**의 경우 Bitbucket 커밋 상태의 `name` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 Bitbucket API 설명서의 [빌드](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build)를 참조하세요.  
**대상 URL**에 Bitbucket 커밋 상태의 `url` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 Bitbucket API 설명서의 [빌드](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build)를 참조하세요.  
Webhook에 의해 트리거된 빌드의 상태는 항상 소스 공급자에게 보고됩니다. 콘솔 또는 API 직접 호출에서 시작된 빌드의 상태를 소스 공급자에게 보고하려면 이 설정을 선택해야 합니다.  
프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

코드 변경 사항이 이 리포지토리에 푸시될 때마다 CodeBuild가 소스 코드를 빌드하도록 하려면 **기본 소스 webhook 이벤트**에서 **코드 변경이 이 리포지토리에 푸시될 때마다 다시 빌드**를 선택합니다. webhook 및 필터 그룹에 대한 자세한 내용은 [Bitbucket Webhook 이벤트](bitbucket-webhook.md) 섹션을 참조하세요.

------
#### [ GitHub ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**GitHub 앱**, **OAuth** 또는 **개인 액세스 토큰**을 선택하여 CodeBuild에 연결합니다.

 **Connection**   
GitHub 연결 또는 Secrets Manager 보안 암호를 선택하여 지정된 연결 유형을 통해 연결합니다.

 **리포지토리**   
**내 GitHub 계정의 리포지토리**, **퍼블릭 리포지토리** 또는 **GitHub 범위 웹후크**를 선택하고 리포지토리 URL을 입력합니다.

 **소스 버전**   
분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 단원을 참조하십시오.  
**상태 컨텍스트**의 경우 GitHub 커밋 상태의 `context` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
**대상 URL**에 GitHub 커밋 상태의 `target_url` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
Webhook에 의해 트리거된 빌드의 상태는 항상 소스 공급자에게 보고됩니다. 콘솔 또는 API 직접 호출에서 시작된 빌드의 상태를 소스 공급자에게 보고하려면 이 설정을 선택해야 합니다.  
프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

코드 변경 사항이 이 리포지토리에 푸시될 때마다 CodeBuild가 소스 코드를 빌드하도록 하려면 **기본 소스 webhook 이벤트**에서 **코드 변경이 이 리포지토리에 푸시될 때마다 다시 빌드**를 선택합니다. webhook 및 필터 그룹에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.

------
#### [ GitHub Enterprise Server ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections** 또는 **개인 액세스 토큰**을 선택하여 CodeBuild에 연결합니다.

 **Connection**   
GitHub Enterprise 연결 또는 Secrets Manager 보안 암호를 선택하여 지정된 연결 유형을 통해 연결합니다.

 **리포지토리**   
**내 GitHub Enterprise 계정의 리포지토리** 또는 **GitHub Enterprise 범위 웹후크**를 선택하고 리포지토리 URL을 입력합니다.

**소스 버전**  
풀 요청, 분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 단원을 참조하십시오.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

**Git clone 깊이**  
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 단원을 참조하십시오.  
**상태 컨텍스트**의 경우 GitHub 커밋 상태의 `context` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
**대상 URL**에 GitHub 커밋 상태의 `target_url` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
Webhook에 의해 트리거된 빌드의 상태는 항상 소스 공급자에게 보고됩니다. 콘솔 또는 API 직접 호출에서 시작된 빌드의 상태를 소스 공급자에게 보고하려면 이 설정을 선택해야 합니다.  
프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

**비보안 SSL**  
GitHub Enterprise 프로젝트 리포지토리에 연결되어 있는 동안 SSL을 무시하려면 **Enable insecure SSL(안전하지 않은 SSL 활성화)**을 선택합니다.

코드 변경 사항이 이 리포지토리에 푸시될 때마다 CodeBuild가 소스 코드를 빌드하도록 하려면 **기본 소스 webhook 이벤트**에서 **코드 변경이 이 리포지토리에 푸시될 때마다 다시 빌드**를 선택합니다. webhook 및 필터 그룹에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.

------
#### [ GitLab ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections**는 GitLab을 CodeBuild에 연결하는 데 사용됩니다.

 **Connection**   
CodeConnections를 통해 연결할 GitLab 연결을 선택합니다.

 **리포지토리**   
사용할 리포지토리를 선택합니다.

 **소스 버전**   
pull 요청, 분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 단원을 참조하십시오.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 단원을 참조하십시오.

------
#### [ GitLab Self Managed ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections**는 GitLab Self Managed를 CodeBuild 연결하는 데 사용됩니다.

 **Connection**   
GitLab Self Managed 연결을 선택하여 CodeConnections 통해 연결합니다.

 **리포지토리**   
사용할 리포지토리를 선택합니다.

 **소스 버전**   
pull 요청, 분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 단원을 참조하십시오.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 단원을 참조하십시오.

------

### 환경
<a name="change-project-console-environment"></a>

**환경** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

**프로비저닝 모델**  
프로비저닝 모델을 변경하려면 **프로비저닝 모델 변경**을 선택하고 다음 중 하나를 수행합니다.  
+ 에서 관리하는 온디맨드 플릿을 사용하려면 **온디맨**드를 AWS CodeBuild선택합니다. CodeBuild는 온디맨드 플릿을 통해 빌드에 맞는 컴퓨팅 기능을 제공합니다. 빌드가 완료되면 머신이 파괴됩니다. 온디맨드 플릿은 완전 관리형이며, 수요 급증을 처리할 수 있는 자동 규모 조정 기능이 포함되어 있습니다.
+ 에서 관리하는 예약 용량 플릿을 사용하려면 **예약 용량을** AWS CodeBuild선택한 다음 **플릿 이름을** 선택합니다. 예약 용량 플릿을 사용하면 빌드 환경을 위한 전용 인스턴스 세트를 구성할 수 있습니다. 이러한 머신은 유휴 상태로 유지되므로 빌드 또는 테스트를 즉시 처리하고 빌드 기간을 단축할 수 있습니다. 예약 용량 플릿을 사용하면 머신이 상시 가동되므로 프로비저닝하는 한 계속해서 비용이 발생합니다.
자세한 내용은 [예약 용량 플릿에서 빌드 실행](fleets.md) 단원을 참조하세요.

**환경 이미지**  
빌드 이미지를 변경하려면 **이미지 재정의**를 선택하고 다음 중 하나를 수행합니다.  
+ 에서 관리하는 Docker 이미지를 사용하려면 **관리형 이미지를** AWS CodeBuild선택한 다음 **운영 체제**, **런타임, 이미지(Image)** 및 **이미지 버전**에서 선택합니다. **** 사용 가능한 경우 **환경 유형**에서 항목을 선택합니다.
+ 다른 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Other registry(다른 레지스트리)**를 선택한 경우 **External registry URL(외부 레지스트리 URL)**에 Docker Hub의 도커 이미지 이름 및 태그를 `docker repository/docker image name` 형식으로 입력합니다. **Amazon ECR**을 선택하는 경우 **Amazon ECR 리포지토리**와 **Amazon ECR 이미지를** 사용하여 AWS 계정에서 도커 이미지를 선택합니다.
+ 프라이빗 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Image registry(이미지 레지스트리)**에서 **Other registry(다른 레지스트리)**를 선택한 다음 프라이빗 도커 이미지에 대한 보안 인증 정보의 ARN을 입력합니다. 보안 인증은 Secrets Manager에서 생성됩니다. 자세한 내용은 AWS Secrets Manager사용 설명서의 [AWS Secrets Manager 이란?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) 섹션을 참조하세요.**
CodeBuild는 사용자 지정 도커 이미지에 대해 `ENTRYPOINT`를 재정의합니다.

**서비스 역할**  
다음 중 하나를 수행하세요.  
+ CodeBuild 서비스 역할이 없는 경우 **새 서비스 역할**을 선택합니다. **역할 이름**에 새 역할의 이름을 입력합니다.
+ CodeBuild 서비스 역할이 있는 경우 **기존 서비스 역할**을 선택합니다. **역할 ARN**에서 서비스 역할을 선택합니다.
콘솔을 사용하여 빌드 프로젝트를 생성하는 경우, 이와 동시에 CodeBuild 서비스 역할을 생성할 수 있습니다. 기본적으로 역할은 해당 빌드 프로젝트에서만 작동합니다. 콘솔을 사용하여 이 서비스 역할을 다른 빌드 프로젝트와 연결하는 경우 다른 빌드 프로젝트에서 작동하도록 역할이 업데이트됩니다. 하나의 서비스 역할은 최대 10개의 빌드 프로젝트에서 작동할 수 있습니다.

**추가 구성**    
**제한 시간**  
빌드가 완료되지 않는 경우 CodeBuild가 해당 빌드를 중지할 제한 시간으로 5분에서 36시간 사이의 값을 지정합니다. [**hours**] 및 [**minutes**]가 비어 있는 경우 기본값인 60분이 사용됩니다.  
**권한 있음**  
이 빌드 프로젝트를 사용하여 Docker 이미지를 빌드하려는 경우에만 **Docker 이미지를 빌드하거나 빌드에서 승격된 권한을 얻으려는 경우 이 플래그 활성화**를 선택합니다. 그렇지 않으면 Docker 데몬과 상호 작용을 시도하는 모든 연결된 빌드가 실패합니다. 또한 빌드가 상호 작용할 수 있도록 Docker 데몬을 시작해야 합니다. 이를 수행하는 한 가지 방법은 다음 빌드 명령을 실행하여 빌드 사양의 `install` 단계에서 Docker 데몬을 초기화하는 것입니다. 선택한 빌드 환경 이미지가 Docker 지원을 통해 CodeBuild에서 제공되지 않는 경우 이 명령을 실행하지 마세요.  
기본적으로 비 VPC 빌드에는 Docker 데몬이 활성화됩니다. VPC 빌드에 Docker 컨테이너를 사용하려면 Docker Docs 웹 사이트의 [런타임 권한 및 Linux 기능](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)을 참조하고 권한 부여 모드를 활성화합니다. 또한 Windows는 권한 모드를 지원하지 않습니다.

```
- nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 &
- timeout 15 sh -c "until docker info; do echo .; sleep 1; done"
```  
**VPC**  
CodeBuild를 사용하여 VPC에서 작업을 수행하려는 경우:  
+ **VPC**에서 CodeBuild가 사용하는 VPC ID를 선택합니다.
+ **VPC 서브넷**에서 CodeBuild가 사용하는 리소스가 포함된 서브넷을 선택합니다.
+ **VPC 보안 그룹**에서 CodeBuild가 VPC의 리소스에 대한 액세스를 허용하기 위해 사용하는 보안 그룹을 선택합니다.
자세한 내용은 [Amazon Virtual Private Cloud AWS CodeBuild 와 함께 사용](vpc-support.md) 단원을 참조하십시오.  
**컴퓨팅**  
사용 가능한 옵션 중 하나를 선택합니다.  
**레지스트리 자격 증명**  
프로젝트가 비공개 레지스트리 이미지로 구성된 경우 레지스트리 자격 증명을 지정합니다.  
이 자격 증명은 이미지가 프라이빗 레지스트리의 이미지로 재정의된 경우에만 사용됩니다.  
**환경 변수**  
사용할 빌드의 각 환경 변수에 대해 이름 및 값을 입력하고 유형을 선택합니다.  
CodeBuild는 AWS 리전의 환경 변수를 자동으로 설정합니다. buildspec.yml에 추가하지 않은 경우 다음 환경 변수를 설정해야 합니다.  
+ AWS\$1ACCOUNT\$1ID
+ IMAGE\$1REPO\$1NAME
+ IMAGE\$1TAG
콘솔과 AWS CLI 사용자는 환경 변수를 볼 수 있습니다. 환경 변수의 가시성에 대한 문제가 없다면 [**Name**] 및 [**Value**] 필드를 설정한 다음 [**Type**]을 [**Plaintext**]로 설정합니다.  
액세스 키 ID, AWS 보안 AWS 액세스 키 또는 암호와 같은 민감한 값을 가진 환경 변수를 Amazon EC2 Systems Manager Parameter Store 또는에 파라미터로 저장하는 것이 좋습니다 AWS Secrets Manager.  
Amazon EC2 Systems Manager Parameter Store를 사용하는 경우 **유형**에서 **파라미터**를 선택합니다. **이름**에 CodeBuild가 참조할 식별자를 입력합니다. **값**에 Amazon EC2 Systems Manager Parameter Store에 저장되는 파라미터의 이름을 입력합니다. 예를 들어 `/CodeBuild/dockerLoginPassword`라는 이름의 파라미터를 사용하여 **유형**에서 **파라미터**를 선택합니다. **이름**에 `LOGIN_PASSWORD`를 입력합니다. **값**에 `/CodeBuild/dockerLoginPassword`를 입력합니다.  
Amazon EC2 Systems Manager Parameter Store를 사용하는 경우 `/CodeBuild/`로 시작하는 파라미터 이름(예: `/CodeBuild/dockerLoginPassword`)으로 파라미터를 저장하는 것이 좋습니다. CodeBuild 콘솔을 사용하여 Amazon EC2 Systems Manager에서 파라미터를 생성할 수 있습니다. **파라미터 생성**을 선택하고 대화 상자에 표시되는 지시에 따릅니다. (그 대화 상자에서 **KMS 키**에 대해 계정에 있는 AWS KMS 키의 ARN을 지정할 수 있습니다. Amazon EC2 Systems Manager는이 키를 사용하여 저장 중에 파라미터의 값을 암호화하고 검색 중에 복호화합니다.) CodeBuild 콘솔을 사용하여 파라미터를 생성하는 경우 콘솔은 이름이 `/CodeBuild/`인 파라미터가 저장되면 시작합니다. 자세한 내용은 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)을 참조하세요.**  
빌드 프로젝트가 Amazon EC2 Systems Manager Parameter Store에 저장된 파라미터를 참조하는 경우 해당 빌드 프로젝트의 서비스 역할은 `ssm:GetParameters` 작업을 허용해야 합니다. 앞에서 **새 서비스 역할**을 선택한 경우에는 CodeBuild는 빌드 프로젝트의 기본 서비스 역할에 이 작업을 포함합니다. **Existing service role(기존 서비스 역할)**을 선택한 경우에는 이 작업을 서비스 역할에 별도로 포함해야 합니다.  
빌드 프로젝트가 `/CodeBuild/`로 시작되지 않는 파라미터 이름으로 Amazon EC2 Systems Manager Parameter Store에 저장된 파라미터를 참조하는 경우 **새 서비스 역할**을 선택하면 `/CodeBuild/`로 시작하지 않는 파라미터 이름에 액세스할 수 있도록 해당 서비스 역할을 업데이트해야 합니다. 이는 서비스 역할이 `/CodeBuild/`로 시작하는 파라미터 이름에만 액세스할 수 있기 때문입니다.  
**새 서비스 역할**을 선택하면 Amazon EC2 Systems Manager Parameter Store에 있는 `/CodeBuild/` 네임스페이스의 모든 파라미터를 해독할 권한이 서비스 역할에 포함됩니다.  
사용자가 설정한 환경 변수는 기존 환경 변수를 대체합니다. 예를 들어 도커 이미지에 값이 `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_`로 시작하는 이름으로 환경 변수를 설정하지 마십시오. 이 접두사는 내부 전용으로 예약되어 있습니다.  
여러 위치에서 동일한 이름의 환경 변수가 정의되는 경우, 다음과 같이 값이 결정됩니다.  
+ 시작 빌드 작업 호출의 값이 가장 높은 우선 순위를 갖습니다.
+ 빌드 프로젝트 정의의 값이 다음 우선 순위를 갖습니다.
+ buildspec 선언의 값이 가장 낮은 우선 순위를 갖습니다.
Secrets Manager를 사용하는 경우 **유형**으로 **Secrets Manager**로 선택합니다. **이름**에 CodeBuild가 참조할 식별자를 입력합니다. **값**에 `secret-id:json-key:version-stage:version-id` 패턴을 사용하여 `reference-key`를 입력합니다. 자세한 내용은 [Secrets Manager reference-key in the buildspec file](build-spec-ref.md#secrets-manager-build-spec) 단원을 참조하세요.  
Secrets Manager를 사용하는 경우 이름이 `/CodeBuild/`로 시작하는 암호를 저장하는 것이 좋습니다(예: `/CodeBuild/dockerLoginPassword`). 자세한 내용은 AWS Secrets Manager사용 설명서의 [AWS Secrets Manager 이란?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 섹션을 참조하세요.**  
빌드 프로젝트가 Secrets Manager에 저장된 암호를 참조하는 경우 해당 빌드 프로젝트의 서비스 역할은 `secretsmanager:GetSecretValue` 작업을 허용해야 합니다. 앞에서 **새 서비스 역할**을 선택한 경우에는 CodeBuild는 빌드 프로젝트의 기본 서비스 역할에 이 작업을 포함합니다. **Existing service role(기존 서비스 역할)**을 선택한 경우에는 이 작업을 서비스 역할에 별도로 포함해야 합니다.  
빌드 프로젝트가 `/CodeBuild/`로 시작되지 않는 보안 암호 이름으로 Secrets Manager에 저장된 암호를 참조하는 경우 **새 서비스 역할**을 선택하면 `/CodeBuild/`로 시작하지 않는 보안 암호 이름에 액세스할 수 있도록 해당 서비스 역할을 업데이트해야 합니다. 이는 서비스 역할이 `/CodeBuild/`로 시작하는 암호 이름에만 액세스할 수 있기 때문입니다.  
**새 서비스 역할**을 선택하면 에 있는 `/CodeBuild/` 네임스페이스의 모든 암호를 해독할 권한이 서비스 역할에 포함됩니다.

### Buildspec
<a name="change-project-console-buildspec"></a>

**Buildspec** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

**빌드 사양**  
다음 중 하나를 수행하세요.  
+ 소스 코드에 buildspec 파일이 있는 경우 **Use a buildspec file(빌드 사양 파일 사용)** 을 선택합니다. 기본적으로 CodeBuild는 소스 코드 루트 디렉터리에서 `buildspec.yml`이라는 파일을 찾습니다. buildspec 파일이 다른 이름이나 위치를 사용하는 경우 **Buildspec 이름**에 소스 루트의 경로를 입력합니다(예: `buildspec-two.yml` 또는 `configuration/buildspec.yml`). buildspec 파일이 S3 버킷에 있는 경우 해당 파일은 빌드 프로젝트와 동일한 AWS 리전에 있어야 합니다. ARN을 사용하여 buildspec 파일을 지정합니다(예: `arn:aws:s3:::<my-codebuild-sample2>/buildspec.yml`).
+ 소스 코드에 buildspec 파일이 포함되어 있지 않거나, 소스 코드의 루트 디렉터리에 있는 `buildspec.yml` 파일의 `build` 단계에 지정된 것과 다른 빌드 명령 세트를 실행하려는 경우 **빌드 명령 삽입**을 선택합니다. **빌드 명령**의 `build` 단계에서 실행하려는 명령을 입력합니다. 명령이 여러 개인 경우 각 명령을 `&&`로 구분합니다(예: `mvn test && mvn package`). 다른 구문에서 명령을 실행하려는 경우 또는 `build` 단계에 대해 특히 긴 명령 목록이 있는 경우에는 소스 코드 루트 디렉터리에 `buildspec.yml` 파일을 추가하고, 이 파일에 명령을 추가한 다음, **소스 코드 루트 디렉터리에서 buildspec.yml 사용**을 선택합니다.
자세한 내용은 [buildspec 참조](build-spec-ref.md) 단원을 참조하십시오.

### 배치 구성
<a name="change-project-console-batch-config"></a>

**배치 구성** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다. 자세한 내용은 [배치로 빌드 실행](batch-build.md) 단원을 참조하십시오.

다음 속성을 수정할 수 있습니다.

**배치 서비스 역할**  
배치 빌드에 대한 서비스 역할을 제공합니다.  
다음 중 하나를 선택합니다.  
+ 배치 서비스 역할이 없는 경우 **새 서비스 역할**을 선택합니다. **서비스 역할**에 새 역할의 이름을 입력합니다.
+ 배치 서비스 역할이 있는 경우 **기존 서비스 역할**을 선택합니다. **서비스 역할**에서 서비스 역할을 선택합니다.
배치 빌드는 배치 구성에 새로운 보안 역할을 도입합니다. CodeBuild가 사용자 대신 `StartBuild`, `StopBuild` 및 `RetryBuild` 작업을 호출하여 배치의 일부로 빌드를 실행할 수 있어야 하므로 이 새 역할이 필요합니다. 고객은 다음과 같은 두 가지 이유로 빌드에 사용하는 것과 동일한 역할이 아닌 새 역할을 사용해야 합니다.  
+ 빌드 역할 `StartBuild`, `StopBuild` 및 `RetryBuild` 권한을 부여하면 단일 빌드에서 buildspec을 통해 더 많은 빌드를 시작할 수 있습니다.
+ CodeBuild 배치 빌드는 배치의 빌드에 사용할 수 있는 빌드 및 컴퓨팅 유형의 수를 제한하는 제한을 제공합니다. 빌드 역할에 이러한 권한이 있는 경우 빌드 자체가 이러한 제한을 우회할 수 있습니다.

**배치에 허용되는 컴퓨팅 유형**  
배치에 허용되는 컴퓨팅 유형을 선택합니다. 해당하는 항목을 모두 선택합니다.

**배치에 허용되는 플릿**  
배치에 허용되는 플릿을 선택합니다. 해당하는 항목을 모두 선택합니다.

**배치에 허용되는 최대 빌드 수**  
배치에 허용되는 최대 빌드 수를 입력합니다. 이 제한을 초과하는 배치는 실패합니다.

**배치 제한 시간**  
배치 빌드가 완료되는 최대 시간을 입력합니다.

**아티팩트 결합**  
**배치의 모든 아티팩트를 단일 위치로 결합**을 선택하면 배치의 모든 아티팩트가 단일 위치로 결합됩니다.

 **배치 보고서 모드**   
배치 빌드에 대해 원하는 빌드 상태 보고서 모드를 선택합니다.  
이 필드는 프로젝트 소스가 Bitbucket, GitHub 또는 GitHub Enterprise이고 **소스**에서 **빌드 시작 및 종료 시 소스 공급자에게 빌드 상태 보고**를 선택한 경우에만 사용할 수 있습니다.  
 **빌드 집계**   
배치의 모든 빌드 상태를 단일 상태 보고서로 통합하려면 선택합니다.  
 **개별 빌드**   
배치에 있는 모든 빌드의 빌드 상태를 별도로 보고하려면 선택합니다.

### 아티팩트
<a name="change-project-console-artifacts"></a>

**아티팩트** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

**유형**  
다음 중 하나를 수행하세요.  
+ 빌드 출력 결과물을 생성하지 않으려면 [**No artifacts**]를 선택합니다. 빌드 테스트만 실행하고 있는 경우 또는 Amazon ECR 리포지토리에 도커 이미지를 푸시하려는 경우에 이 작업을 원할 수 있습니다.
+ S3 버킷에 빌드 출력을 저장하려면 **Amazon S3**를 선택하고 다음 작업을 수행합니다.
  + 빌드 출력 ZIP 파일이나 폴더에 프로젝트 이름을 사용하려는 경우 **이름**을 비워 둡니다. 그렇지 않으면 이름을 입력합니다. (ZIP 파일을 출력하고 ZIP 파일에 파일 확장명을 넣으려는 경우, ZIP 파일 이름 뒤에 이를 포함하십시오.)
  + buildspec 파일에 지정된 이름으로 콘솔에서 지정한 이름을 재정의하려는 경우 **의미 체계 버전 관리 사용**을 선택합니다. buildspec 파일의 이름은 빌드 시 계산되며 Shell 명령 언어를 사용합니다. 예를 들어 아티팩트 이름이 항상 고유하도록 날짜와 시간을 아티팩트 이름에 추가할 수 있습니다. 고유한 결과물 이름을 사용하면 결과물을 덮어쓰지 않을 수 있습니다. 자세한 내용은 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax) 단원을 참조하십시오.
  + [**Bucket name**]에서 출력 버킷의 이름을 선택합니다.
  + 이 절차의 앞부분에서 **빌드 명령 삽입**을 선택한 경우 **출력 파일**에 빌드 출력 ZIP 파일 또는 폴더에 넣으려는 빌드의 파일 위치를 입력합니다. 위치가 여러 개인 경우 각 위치를 쉼표로 구분합니다(예: `appspec.yml, target/my-app.jar`). 자세한 내용은 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax)의 `files` 설명을 참조하십시오.
  + 빌드 아티팩트를 암호화하지 않으려면 **Remove artifacts encryption(결과물 암호화 제거)**을 선택합니다.
각각 원하는 보조 아티팩트 세트마다 다음과 같이 실행합니다.  

1. **Atrifact identifier(아티팩트 식별자)**에서 128자 미만으로 영숫자와 밑줄만 포함된 값을 입력합니다.

1. **Add artifact(아티팩트 추가)**를 선택합니다.

1. 이전 단계에 따라 보조 결과물을 구성합니다.

1. **Save artifact(아티팩트 저장)**를 선택합니다.

**추가 구성**    
**암호화 키**  
다음 중 하나를 수행하세요.  
+ 계정의 AWS 관리형 키 Amazon S3를 사용하여 빌드 출력 아티팩트를 암호화하려면 **암호화 키를** 비워 둡니다. 기본값입니다.
+ 고객 관리형 키를 사용하여 빌드 출력 아티팩트를 암호화하려면 **암호화 키**에 고객 관리형 키의 ARN을 입력합니다. `arn:aws:kms:region-ID:account-ID:key/key-ID` 형식을 사용합니다.  
**캐시 유형**  
**Cache type(캐시 유형)**에서 다음 중 하나를 선택합니다.  
+ 캐시를 사용하지 않으려면 [**No cache**]를 선택합니다.
+ Amazon S3 캐시를 사용하려면 **Amazon S3**를 선택하고 다음을 수행합니다.
  + **버킷**에서 캐시가 저장된 S3 버킷의 이름을 선택합니다.
  + (선택 사항) **캐시 경로 접두사**에 Amazon S3 경로 접두사를 입력합니다. **Cache path prefix(캐시 경로 접두사)** 값은 디렉터리 이름과 비슷합니다. 따라서 캐시를 버킷의 동일한 디렉터리에 저장할 수 있습니다.
**중요**  
경로 접두사 끝에 후행 슬래시(/)를 추가하지 마십시오.
+  로컬 캐시를 사용하려면 **로컬**을 선택한 다음 하나 이상의 로컬 캐시 모드를 선택해야 합니다.
**참고**  
Docker 계층 캐시 모드는 Linux에서만 사용할 수 있습니다. 이 모드를 선택할 경우 프로젝트를 권한이 있는 모드에서 실행해야 합니다.
캐시를 사용하면 빌드 환경의 재사용 가능한 특정 부분이 캐시에 저장되고 빌드 전반에서 사용되기 때문에 상당한 빌드 시간을 절약할 수 있습니다. buildspec 파일에 캐시를 지정하는 것에 대한 자세한 정보는 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax) 단원을 참조하십시오. 캐싱에 대한 자세한 정보는 [성능을 개선하기 위한 캐시 빌드](build-caching.md)을 참조하십시오.

### 로그
<a name="change-project-console-logs"></a>

**로그** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

생성하려는 로그를 선택합니다. Amazon CloudWatch Logs 또는 Amazon S3 로그 중 하나 또는 둘 다를 생성할 수 있습니다.

**CloudWatch**  
Amazon CloudWatch Logs 로그를 원할 경우:    
**CloudWatch 로그**  
**CloudWatch 로그**를 선택합니다.  
**그룹 이름**  
Amazon CloudWatch Logs 로그 그룹의 이름을 입력합니다.  
**스트림 이름**  
Amazon CloudWatch Logs 로그 스트림 이름을 입력합니다.

**S3**  
Amazon S3 로그를 원할 경우:    
**S3 로그**  
**S3 로그**를 선택합니다.  
**버킷**  
로그에 대한 S3 버킷 이름을 선택합니다.  
**경로 접두사**  
로그의 접두사를 입력합니다.  
**S3 로그 암호화 비활성화**  
S3 로그를 암호화하지 않으려면 선택합니다.

## 빌드 프로젝트 설정 변경(AWS CLI)
<a name="change-project-cli"></a>

와 AWS CLI 함께를 사용하는 방법에 대한 자세한 내용은 단원을 AWS CodeBuild참조하십시오[명령줄 참조](cmd-ref.md).

를 사용하여 CodeBuild 프로젝트를 업데이트하려면 업데이트된 속성으로 JSON 파일을 AWS CLI생성하고 해당 파일을 [https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html) 명령에 전달합니다. 업데이트 파일에 포함되지 않은 속성은 변경되지 않습니다.

업데이트 JSON 파일에는 `name` 속성과 수정된 속성만 필요합니다. `name` 속성은 수정할 프로젝트를 식별합니다. 수정된 구조의 경우 해당 구조의 필수 파라미터도 포함되어야 합니다. 예를 들어, 프로젝트에 대한 환경을 수정하려면 `environment/type` 및 `environment/computeType` 속성이 필요합니다. 다음은 환경 이미지를 업데이트하는 예입니다.

```
{
  "name": "<project-name>",
  "environment": {
    "type": "LINUX_CONTAINER",
    "computeType": "BUILD_GENERAL1_SMALL",
    "image": "aws/codebuild/amazonlinux-x86_64-standard:4.0"
  }
}
```

프로젝트의 현재 속성 값을 가져와야 하는 경우 [https://docs.aws.amazon.com/cli/latest/reference/codebuild/batch-get-projects.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/batch-get-projects.html) 명령을 사용하여 수정하려는 프로젝트의 현재 속성을 가져오고 결과를 파일에 기록합니다.

```
aws codebuild batch-get-projects --names "<project-name>" > project-info.json
```

*project-info.json* 파일에는 프로젝트 배열이 포함되어 있으므로 프로젝트를 업데이트하는 데 직접 사용할 수는 없습니다. 하지만 *project-info.json* 파일에서 수정하려는 속성을 복사한 다음, 수정하려는 속성의 기준으로 업데이트 파일에 붙여넣을 수 있습니다. 자세한 내용은 [빌드 프로젝트 세부 정보 보기(AWS CLI)](view-project-details.md#view-project-details-cli) 단원을 참조하십시오.

[빌드 프로젝트 생성(AWS CLI)](create-project.md#create-project-cli)에 설명된 대로 업데이트 JSON 파일을 수정하고 결과를 저장합니다. 업데이트 JSON 파일의 수정이 끝나면 [https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html) 명령을 실행하여 업데이트 JSON 파일을 전달합니다.

```
aws codebuild update-project --cli-input-json file://<update-project-file>
```

성공하면 업데이트된 프로젝트 JSON이 출력에 나타납니다. 필수 파라미터가 누락된 경우 누락된 파라미터를 식별하는 오류 메시지가 출력에 표시됩니다. 예를 들어, `environment/type` 파라미터가 누락된 경우 표시되는 오류 메시지는 다음과 같습니다.

```
aws codebuild update-project --cli-input-json file://update-project.json

Parameter validation failed:
Missing required parameter in environment: "type"
```

## 빌드 프로젝트의 설정 변경(AWS SDKs)
<a name="change-project-sdks"></a>

를 SDK와 AWS CodeBuild 함께 사용하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS SDKs 및 도구 참조](sdk-ref.md). AWS SDKs

# CodeBuild의 다중 액세스 토큰
<a name="multiple-access-tokens"></a>

CodeBuild는 AWS Secrets Manager 또는 AWS CodeConnections 연결을 통해 보안 암호에서 타사 공급자에게 액세스 토큰 소싱을 지원합니다. 보안 암호 또는 연결을 GitHub, GitHub Enterprise 또는 Bitbucket과 같은 지정된 타사 공급자와의 상호 작용을 위한 기본 자격 증명으로 설정할 수 있습니다.

소스 자격 증명을 세 가지 다른 수준에서 설정할 수 있습니다.

1. **모든 프로젝트의 계정 수준 자격 증명:** 이는 AWS 계정의 모든 프로젝트에 대한 기본 자격 증명입니다. 프로젝트 또는 소스 수준 자격 증명이 지정되지 않은 경우 프로젝트에 사용됩니다.

1. **특정 리포지토리의 소스 수준 자격 증명:** Secrets Manager 보안 암호 또는 CodeConnections 연결이 프로젝트 소스에 정의된 경우입니다. 이러한 자격 증명은 지정된 소스 리포지토리의 작업에만 사용됩니다. 이렇게 하면 동일한 프로젝트에서 서로 다른 권한 범위를 가진 다중 액세스 토큰을 설정할 수 있으며 기본 계정 수준 자격 증명을 사용하지 않을 수 있습니다.

1. **프로젝트 수준 대체 자격 증명:** `NO_SOURCE`를 기본 소스 유형으로 사용하여 프로젝트 수준 대체 자격 증명을 설정하고 보안 암호 또는 연결을 정의할 수 있습니다. 프로젝트에 여러 소스가 있지만 동일한 자격 증명을 사용하려는 경우 또는 프로젝트에 기본 계정 수준 자격 증명을 사용하지 않으려는 경우에 사용할 수 있습니다.

**Topics**
+ [1단계: Secrets Manager 보안 암호 또는 CodeConnections 연결 생성](#create-secret-connection)
+ [2단계: Secrets Manager 보안 암호에 대한 IAM 역할 액세스 권한을 CodeBuild 프로젝트에 부여](#asm-role-access)
+ [3단계: Secrets Manager 또는 CodeConnections 토큰 구성](#asm-account-credential)
+ [추가 설정 옵션](#asm-credential-cfn)

## 1단계: Secrets Manager 보안 암호 또는 CodeConnections 연결 생성
<a name="create-secret-connection"></a>

다음 지침을 사용하여 Secrets Manager 보안 암호 또는 CodeConnections 연결을 생성합니다.
+ [Secrets Manager 보안 암호에 토큰 생성 및 저장](asm-create-secret.md).
+ [GitHub에 대한 연결 생성](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-create-github.html)
+ [GitHub Enterprise Server에 대한 연결 생성](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-create-gheserver.html)
+ [Bitbucket에 대한 연결 생성](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-create-bitbucket.html)

## 2단계: Secrets Manager 보안 암호에 대한 IAM 역할 액세스 권한을 CodeBuild 프로젝트에 부여
<a name="asm-role-access"></a>

**참고**  
계속하려면 Secrets Manager 또는 CodeConnections에서 생성된 토큰에 액세스할 수 있어야 합니다.

CodeBuild 프로젝트에 Secrets Manager 또는 CodeConnections에 대한 IAM 역할 액세스 권한을 부여하려면 다음 IAM 정책을 추가해야 합니다.

**CodeBuild 프로젝트에 IAM 역할 액세스 권한을 부여하려면**

1. CodeBuild 프로젝트의 [CodeBuild가 다른 AWS 서비스와 상호 작용하도록 허용](setting-up-service-role.md)에 대한 지침에 따라 CodeBuild 프로젝트의 IAM 역할을 생성합니다.

1. 다음 중 하나를 수행하세요.
   + CodeBuild 프로젝트 역할에 보안 암호에 대한 액세스 권한을 부여하는 다음 IAM 정책을 추가합니다.

------
#### [ JSON ]

****  

     ```
     {
         "Version":"2012-10-17",		 	 	 
         "Statement": [
             {
                 "Effect": "Allow",
                 "Action": [
                     "secretsmanager:GetSecretValue"
                 ],
                 "Resource": [
                     "arn:aws:iam::*:role/Service*"
                 ]
             }
         ]
     }
     ```

------

     (선택 사항) AWS KMS 고객 관리형 키를 사용하여 Secrets Manager 보안 암호를 암호화하는 경우 다음 정책 설명을 추가하여 액세스 권한을 부여할 수 있습니다.

------
#### [ JSON ]

****  

     ```
     {
         "Version":"2012-10-17",		 	 	 
         "Statement": [
             {
                 "Effect": "Allow",
                 "Action": [
                     "kms:Decrypt"
                 ],
                 "Resource": "arn:aws:iam::*:role/Service*",
                 "Condition": {
                     "StringEquals": {
                         "kms:EncryptionContext:SecretARN": "arn:aws:iam::*:role/Service*"
                     }
                 }
             }
         ]
     }
     ```

------
   + CodeBuild 프로젝트 역할에 연결에 대한 액세스 권한을 부여하는 다음 IAM 정책을 추가합니다.

------
#### [ JSON ]

****  

     ```
     {
         "Version":"2012-10-17",		 	 	 
         "Statement": [
             {
                 "Effect": "Allow",
                 "Action": [
                     "codeconnections:GetConnectionToken",
                     "codeconnections:GetConnection"
                 ],
                 "Resource": [
                     "arn:aws:iam::*:role/Service*"
                 ]
             }
         ]
     }
     ```

------

## 3단계: Secrets Manager 또는 CodeConnections 토큰 구성
<a name="asm-account-credential"></a>

Secrets Manager 또는 CodeConnections 토큰을 사용하여 소스 자격 증명을 세 가지 다른 수준으로 설정할 수 있습니다.

### Secrets Manager 또는 CodeConnections 토큰을 계정 수준 자격 증명으로 구성
<a name="asm-account-credential"></a>

Secrets Manager 보안 암호 또는 CodeConnections 연결을 계정 수준 자격 증명으로 구성하고 프로젝트에서 사용할 수 있습니다.

------
#### [ AWS Management Console ]

**에서 연결을 계정 수준 자격 증명으로 구성하려면 AWS Management Console**

1. **소스 공급자**에서 **Bitbucket**, **GitHub** 또는 **GitHub Enterprise**를 선택합니다.

1. **자격 증명**에서 다음 중 하나를 수행합니다.
   + **기본 소스 자격 증명**을 선택하여 계정의 기본 소스 자격 증명을 사용하여 모든 프로젝트에 적용합니다.

     1. 소스 공급자에 연결되지 않은 경우 **기본 소스 자격 증명 관리**를 선택합니다.

     1. **자격 증명 유형**에서 자격 증명 유형을 선택합니다.

     1. **CodeConnections** 선택한 경우 기존 연결을 사용하거나 새 연결을 생성하도록 선택합니다.

        다른 자격 증명 유형을 선택한 경우 **서비스**에서 토큰을 저장하는 데 사용할 서비스를 선택하고 다음을 수행합니다.
        + **Secrets Manager**를 사용하도록 선택한 경우 기존 보안 암호 연결을 사용하거나 새 보안 암호를 생성하고 **저장**을 선택할 수 있습니다. 새 암호를 생성하는 방법에 대한 자세한 정보는 [Secrets Manager 보안 암호에 토큰 생성 및 저장](asm-create-secret.md) 섹션을 참조하세요.
        + **CodeBuild** 사용하도록 선택한 경우 토큰 또는 사용자 이름과 앱 암호를 입력하고 **저장**을 선택합니다.
   + **사용자 지정 소스 자격 증명**을 선택하여 사용자 지정 소스 자격 증명을 사용하여 계정의 기본 설정을 재정의합니다.

     1. **자격 증명 유형**에서 자격 증명 유형을 선택합니다.

     1. **연결**에서 기존 연결을 선택하거나 연결을 새로 생성합니다.

------
#### [ AWS CLI ]

**에서 연결을 계정 수준 자격 증명으로 구성하려면 AWS CLI**
+ 터미널(Linux, macOS, Unix) 또는 명령 프롬프트(Windows)를 엽니다. AWS CLI 를 사용하여 **import-source-credentials** 명령을 실행합니다.

  다음 명령을 사용하여 Secrets Manager 보안 암호를 구성합니다.

  ```
  aws codebuild import-source-credentials \
      --token "<secret-arn>" \
      --server-type <source-provider> \
      --auth-type SECRETS_MANAGER \
      --region <aws-region>
  ```

  다음 명령을 사용하여 CodeConnections 연결을 구성합니다.

  ```
  aws codebuild import-source-credentials \
      --token "<connection-arn>" \
      --server-type <source-provider> \
      --auth-type CODECONNECTIONS \
      --region <aws-region>
  ```

  이 명령을 사용하면 토큰을 계정 수준 기본 소스 자격 증명으로 가져올 수 있습니다. [ImportSourceCredentials](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ImportSourceCredentials.html) API를 사용하여 자격 증명을 가져올 때 CodeBuild는 프로젝트에 더 구체적인 자격 증명 세트가 구성되지 않은 한 웹후크, 빌드 상태 보고 및 git 복제 작업과 같은 소스 공급자와의 모든 상호 작용에 토큰을 사용합니다.

------

이제 빌드 프로젝트에서 토큰을 사용하고 실행할 수 있습니다. 자세한 내용은 [에서 빌드 프로젝트 생성AWS CodeBuild](create-project.md) 및 [수동으로 AWS CodeBuild 빌드 실행](run-build.md) 섹션을 참조하세요.

### 여러 토큰을 소스 수준 자격 증명으로 구성
<a name="asm-source-credential"></a>

Secrets Manager 보안 암호 또는 CodeConnections 연결을 소스 수준 자격 증명으로 사용하려면 CodeBuild 프로젝트의 토큰을 직접 참조하고 빌드를 시작합니다.

------
#### [ AWS Management Console ]

**에서 여러 토큰을 소스 수준 자격 증명으로 구성하려면 AWS Management Console**

1. **소스 공급자**에서 **GitHub**를 선택합니다.

1. **자격 증명**에서 다음 중 하나를 수행합니다.
   + **기본 소스 자격 증명**을 선택하여 계정의 기본 소스 자격 증명을 사용하여 모든 프로젝트에 적용합니다.

     1. GitHub에 연결되지 않은 경우 **기본 소스 자격 증명 관리**를 선택합니다.

     1. **자격 증명 유형**에서 **GitHub 앱**을 선택합니다.

     1. **연결**에서 기존 연결을 선택하거나 연결을 새로 생성합니다.
   + **사용자 지정 소스 자격 증명**을 선택하여 사용자 지정 소스 자격 증명을 사용하여 계정의 기본 설정을 재정의합니다.

     1. **자격 증명 유형**에서 **GitHub 앱**을 선택합니다.

     1. **연결**에서 기존 연결을 선택하거나 연결을 새로 생성합니다.

1. **소스 추가**를 선택하고 소스 공급자 및 자격 증명을 선택하는 프로세스를 반복합니다.

------
#### [ AWS CLI ]

**에서 여러 토큰을 소스 수준 자격 증명으로 구성하려면 AWS CLI**
+ 터미널(Linux, macOS, Unix) 또는 명령 프롬프트(Windows)를 엽니다. AWS CLI 를 사용하여 **create-project** 명령을 실행합니다.

  다음 명령을 사용합니다.

  ```
  aws codebuild create-project --region <aws-region> \
      --name <project-name> \
      --artifacts type=NO_ARTIFACTS \
      --environment "type=LINUX_CONTAINER,
                     computeType=BUILD_GENERAL1_SMALL,
                     image=aws/codebuild/amazonlinux-x86_64-standard:5.0" \
      --service-role <service-role-name> \
      --source "type=GITHUB,
                location=<github-repository-1>,
                auth={type=SECRETS_MANAGER,resource=<secret-or-connection-arn-1>}" \
      --secondary-sources "type=GITHUB,
                location=<github-repository-2>,
                auth={type=SECRETS_MANAGER,resource=<secret-or-connection-arn-2>},
                sourceIdentifier=secondary"
  
  aws codebuild start-build --region <aws-region> --project-name <project-name>
  ```

------

### 프로젝트 수준 소스 자격 증명 대체 설정
<a name="asm-project-credential"></a>

프로젝트 수준 소스 자격 증명 대체를 설정하려면 프로젝트의 기본 소스에 `NO_SOURCE`를 사용하고 토큰을 참조합니다.

```
aws codebuild create-project \
    --name <project-name> \
    --service-role <service-role-name> \
    --artifacts type=NO_ARTIFACTS \
    --environment "type=LINUX_CONTAINER,
                   computeType=BUILD_GENERAL1_SMALL,
                   image=aws/codebuild/amazonlinux-x86_64-standard:5.0" \
    --service-role <service-role-name> \
    --source "type=NO_SOURCE,
              auth={type=SECRETS_MANAGER,resource=<secret-or-connection-arn>},
              buildspec=<buildspec>"
    --secondary-sources "type=GITHUB,
                         location=<github-repository>,
                         sourceIdentifier=secondary"

aws codebuild start-build --region <aws-region> --project-name <project_name>
```

`NO_SOURCE`를 사용하는 경우 일반적으로 외부 소스를 사용하여 [buildspec](build-spec-ref.md)을 가져오도록 직접 구성되지 않았으므로 소스 모델 내에 buildspec이 제공됩니다. 일반적으로 `NO_SOURCE` 소스는 buildspec 내에서 모든 관련 리포지토리 복제를 처리합니다. 이러한 작업에 대해 구성된 자격 증명을 사용할 수 있도록 하려면 buildspec에서 `git-credential-helper` 옵션을 활성화할 수 있습니다.

```
env:
  git-credential-helper: yes
```

빌드 중에 CodeBuild는 구성된 토큰에서 `AuthServer` 필드를 읽고 해당 특정 타사 소스 공급자에 대한 모든 git 요청에 토큰 자격 증명을 사용합니다.

## 추가 설정 옵션
<a name="asm-credential-cfn"></a>

 CloudFormation 템플릿을 사용하여 Secrets Manager 계정 수준 자격 증명을 구성할 수 있습니다. 다음 CloudFormation 템플릿을 사용하여 계정 수준 자격 증명을 설정할 수 있습니다.

```
Parameters:
  GitHubToken:
    Type: String
    NoEcho: true
    Default: placeholder
Resources:
  CodeBuildAuthTokenSecret:
    Type: AWS::SecretsManager::Secret
    Properties:
      Description: CodeBuild auth token
      Name: codebuild-auth-token
      SecretString:
        !Join
          - ''
          - - '{"ServerType":"GITHUB","AuthType":"PERSONAL_ACCESS_TOKEN","Token":"'
            - !Ref GitHubToken
            - '"}'
      Tags:
        - Key: codebuild:source:provider
          Value: github
        - Key: codebuild:source:type
          Value: personal_access_token
  CodeBuildSecretsManagerAccountCredential:
    Type: AWS::CodeBuild::SourceCredential
    Properties:
      ServerType: GITHUB
      AuthType: SECRETS_MANAGER
      Token: !Ref CodeBuildAuthTokenSecret
```

**참고**  
동일한 스택에서 프로젝트를 생성하는 경우 [DependsOn](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-dependson.html) CloudFormation 속성을 사용하여 프로젝트 전에 `AccountCredential`이 생성되도록 합니다.

 CloudFormation 템플릿을 사용하여 Secrets Manager 다중 소스 수준 자격 증명을 구성할 수도 있습니다. 다음 CloudFormation 템플릿을 사용하여 여러 토큰을 사용하여 여러 소스를 가져올 수 있습니다.

```
Parameters:
  GitHubTokenOne:
    Type: String
    NoEcho: true
    Default: placeholder
  GitHubTokenTwo:
    Type: String
    NoEcho: true
    Default: placeholder

Resources:
  CodeBuildSecretsManagerProject:
    Type: AWS::CodeBuild::Project
    Properties:
      Name: codebuild-multitoken-example
      ServiceRole: <service-role>
      Environment:
        Type: LINUX_CONTAINER
        ComputeType: BUILD_GENERAL1_SMALL
        Image: aws/codebuild/amazonlinux-x86_64-standard:5.0
      Source:
        Type: GITHUB
        Location: <github-repository-one>
        Auth:
          Type: SECRETS_MANAGER
          Resource: !Ref CodeBuildAuthTokenSecretOne
      SecondarySources:
        - Type: GITHUB
          Location: <github-repository-two>
          Auth:
            Type: SECRETS_MANAGER
            Resource: !Ref CodeBuildAuthTokenSecretTwo
          SourceIdentifier: secondary
      Artifacts:
        Type: NO_ARTIFACTS
      LogsConfig:
        CloudWatchLogs:
          Status: ENABLED
  CodeBuildProjectIAMRoleSecretAccess:
    Type: AWS::IAM::RolePolicy
    Properties:
      RoleName: <role-name>
      PolicyName: CodeBuildProjectIAMRoleSecretAccessPolicy
      PolicyDocument:
        Version: '2012-10-17		 	 	 '
        Statement:
          - Effect: Allow
            Action:
              - secretsmanager:GetSecretValue
            Resource:
              - !Ref CodeBuildAuthTokenSecretOne
              - !Ref CodeBuildAuthTokenSecretTwo
  CodeBuildAuthTokenSecretOne:
    Type: AWS::SecretsManager::Secret
    Properties:
      Description: CodeBuild auth token one
      Name: codebuild-auth-token-one
      SecretString:
        !Join
          - ''
          - - '{"ServerType":"GITHUB","AuthType":"PERSONAL_ACCESS_TOKEN","Token":"'
            - !Ref GitHubTokenOne
            - '"}'
      Tags:
        - Key: codebuild:source:provider
          Value: github
        - Key: codebuild:source:type
          Value: personal_access_token
  CodeBuildAuthTokenSecretTwo:
    Type: AWS::SecretsManager::Secret
    Properties:
      Description: CodeBuild auth token two
      Name: codebuild-auth-token-two
      SecretString:
        !Join
          - ''
          - - '{"ServerType":"GITHUB","AuthType":"PERSONAL_ACCESS_TOKEN","Token":"'
            - !Ref GitHubTokenTwo
            - '"}'
      Tags:
        - Key: codebuild:source:provider
          Value: github
        - Key: codebuild:source:type
          Value: personal_access_token
```

# AWS CodeBuild에서 빌드 프로젝트 삭제
<a name="delete-project"></a>

CodeBuild 콘솔, AWS CLI 또는 AWS SDK를 사용하여 CodeBuild에서 빌드 프로젝트를 삭제할 수 있습니다. 프로젝트를 삭제하면 해당 빌드가 삭제되지 않습니다.

**주의**  
빌드 및 리소스 정책이 있는 프로젝트는 삭제할 수 없습니다. 리소스 정책 및 빌드가 있는 프로젝트를 삭제하려면 먼저 리소스 정책을 제거하고 빌드를 삭제합니다.

**Topics**
+ [빌드 프로젝트 삭제(콘솔)](#delete-project-console)
+ [빌드 프로젝트 삭제(AWS CLI)](#delete-project-cli)
+ [빌드 프로젝트 삭제(AWS SDK)](#delete-project-sdks)

## 빌드 프로젝트 삭제(콘솔)
<a name="delete-project-console"></a>

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)에서 AWS CodeBuild 콘솔을 엽니다.

1. 탐색 창에서 **프로젝트 빌드**를 선택합니다.

1. 다음 중 하나를 수행합니다.
   + 삭제하려는 빌드 프로젝트 옆에 있는 라디오 버튼을 선택한 후 **삭제**를 선택합니다.
   + 삭제하려는 빌드 프로젝트의 링크를 선택한 다음, [**Delete**]를 선택합니다.
**참고**  
기본적으로 가장 최근에 실행한 10개의 빌드 프로젝트가 표시됩니다. 더 많은 빌드 프로젝트를 보려면 **Projects per page(페이지당 프로젝트)**에서 다른 값을 선택하거나 뒤로 및 앞으로 화살표를 선택하여 프로젝트를 봅니다.

## 빌드 프로젝트 삭제(AWS CLI)
<a name="delete-project-cli"></a>

1. `delete-project` 명령을 실행합니다.

   ```
   aws codebuild delete-project --name name
   ```

   다음과 같이 자리 표시자를 바꿉니다.
   + *name*: 필수 문자열입니다. 삭제할 빌드 프로젝트의 이름입니다. 사용 가능한 빌드 프로젝트 목록을 보려면 `list-projects` 명령을 실행합니다. 자세한 내용은 [빌드 프로젝트 이름 목록 보기(AWS CLI)](view-project-list.md#view-project-list-cli) 섹션을 참조하세요.

1. 이 명령이 제대로 실행되면 출력에 데이터나 오류가 표시되지 않습니다.

AWS CLI와 AWS CodeBuild를 함께 사용하는 방법에 대한 자세한 정보는 [명령줄 참조](cmd-ref.md) 단원을 참조하십시오.

## 빌드 프로젝트 삭제(AWS SDK)
<a name="delete-project-sdks"></a>

AWS CodeBuild와 AWS SDK를 함께 사용하는 방법에 대한 자세한 내용은 [AWS SDKs 및 도구 참조](sdk-ref.md) 단원을 참조하십시오.

# 퍼블릭 빌드 프로젝트 URL 가져오기
<a name="public-builds"></a>

AWS CodeBuild에서 빌드 프로젝트의 빌드 결과, 로그, 아티팩트를 일반 사용자에게 공개할 수 있습니다. 이렇게 하면 소스 리포지토리의 기여자가 AWS 계정에 액세스할 필요 없이 빌드의 결과를 보고 아티팩트를 다운로드할 수 있습니다.<a name="public-builds.warning"></a>

프로젝트의 빌드를 공개하면 프로젝트가 프라이빗일 때 실행된 빌드를 포함하여 프로젝트의 모든 빌드 결과, 로그, 아티팩트는 누구나 사용할 수 있습니다. 마찬가지로 퍼블릭 빌드 프로젝트를 프라이빗으로 설정하면 해당 프로젝트의 빌드 결과를 더 이상 공개할 수 없습니다.

프로젝트 빌드 결과의 퍼블릭 가시성을 변경하는 방법에 대한 자세한 내용은 [퍼블릭 빌드 액세스 활성화](change-project.md#change-project-console.public-builds) 섹션을 참조하세요.

CodeBuild는 프로젝트에 고유한 퍼블릭 빌드의 URL을 제공합니다.

빌드 프로젝트의 퍼블릭 URL을 가져오려면 다음 절차를 수행하세요.

**퍼블릭 빌드 프로젝트의 URL을 가져오려면**

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)에서 AWS CodeBuild 콘솔을 엽니다.

1. 탐색 창에서 **프로젝트 빌드**를 선택합니다.

1. 퍼블릭 URL을 가져오려는 빌드 프로젝트의 링크를 선택합니다.

1. 퍼블릭 URL은 **구성** 섹션의 **퍼블릭 프로젝트 URL** 필드에 표시됩니다. 링크를 선택하여 URL을 열거나 복사 버튼을 사용하여 URL을 복사할 수 있습니다.<a name="public-build-warning"></a>

**주의**  
프로젝트의 빌드 결과를 공개할 때는 다음 사항을 염두에 두어야 합니다.  
프로젝트가 프라이빗일 때 실행된 빌드를 포함하여 프로젝트의 모든 빌드 결과, 로그, 아티팩트는 누구나 이용할 수 있습니다.
모든 빌드 로그와 아티팩트는 누구나 이용할 수 있습니다. 환경 변수, 소스 코드 및 기타 중요한 정보가 빌드 로그와 아티팩트에 출력되었을 수 있습니다. 빌드 로그에 출력되는 정보에 주의해야 합니다. 몇 가지 모범 사례는 다음과 같습니다.  
중요한 값(특히 AWS 액세스 키 ID 및 비밀 액세스 키)은 환경 변수에 저장하지 마세요. Amazon EC2 Systems Manager Parameter Store 또는 AWS Secrets Manager을 사용하여 중요한 값을 저장하는 것이 좋습니다.
webhook를 최대한 안전하게 보호하려면 [webhook 사용 모범 사례](webhooks.md#webhook-best-practices)에 따라 빌드를 트리거할 수 있는 엔터티를 제한하고, buildspec을 프로젝트 자체에 저장하지 마세요.
악의적인 사용자는 퍼블릭 빌드를 사용하여 악성 아티팩트를 배포할 수 있습니다. 프로젝트 관리자는 모든 풀 요청을 검토하여 풀 요청이 합법적인 변경인지 확인하는 것이 좋습니다. 또한 체크섬으로 모든 아티팩트의 유효성을 검사하여 올바른 아티팩트가 다운로드되고 있는지 확인하는 것이 좋습니다.

# 빌드 프로젝트 공유
<a name="project-sharing"></a>

프로젝트 공유를 통해 프로젝트 소유자는 AWS CodeBuild 프로젝트를 다른 AWS 계정 또는 사용자와 공유할 수 있습니다. 이 모델에서는 프로젝트를 소유한 계정(소유자)이 다른 계정(소비자)과 프로젝트를 공유합니다. 소비자는 프로젝트를 편집하거나 실행할 수 없습니다.

**Topics**
+ [프로젝트 공유](#project-sharing-share)
+ [관련 서비스](#project-sharing-related)
+ [사용자와 공유된 CodeBuild 프로젝트 액세스](project-sharing-access-prereqs.md)
+ [공유 프로젝트의 공유 해제](project-sharing-unshare.md)
+ [공유 프로젝트 식별](project-sharing-identify.md)
+ [공유 프로젝트 권한](project-sharing-perms.md)

## 프로젝트 공유
<a name="project-sharing-share"></a>

소비자는 AWS CLI 및 AWS CodeBuild 콘솔을 모두 사용하여 공유한 프로젝트와 빌드를 볼 수 있습니다. 소비자는 프로젝트를 편집하거나 실행할 수 없습니다.

기존 리소스 공유에 프로젝트를 추가하거나 [AWS RAM 콘솔](https://console.aws.amazon.com/ram)에서 프로젝트를 만들 수 있습니다.

**참고**  
리소스 공유에 추가된 빌드가 있는 프로젝트는 삭제할 수 없습니다.

프로젝트를 조직 단위 또는 전체 조직과 공유하려면 AWS Organizations와의 공유를 활성화해야 합니다. 자세한 내용은 *AWS RAM 사용 설명서*에서 [AWS Organizations를 사용하여 공유 사용](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html)을 참조하세요.

 AWS CodeBuild 콘솔, AWS RAM 콘솔 또는를 사용하여 소유한 프로젝트를 AWS CLI 공유할 수 있습니다.

**프로젝트 공유를 위한 전제 조건**  
프로젝트 공유를 시작하기 전에 AWS 계정이 프로젝트를 소유하고 있는지 확인합니다. 사용자와 공유된 프로젝트를 공유할 수 없습니다.

**소유한 프로젝트를 공유하려면(CodeBuild 콘솔)**

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.

1. 탐색 창에서 **프로젝트 빌드**를 선택합니다.
**참고**  
기본적으로 가장 최근의 빌드 프로젝트 10개만 표시됩니다. 더 많은 빌드 프로젝트를 보려면 기어 아이콘을 선택하고 **페이지당 프로젝트 수**에서 다른 값을 선택하거나 뒤로 및 앞으로 화살표를 사용합니다.

1. 공유할 프로젝트를 선택한 다음 **공유**를 선택합니다. 자세한 내용은AWS RAM 사용 설명서의 [리소스 공유 생성](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-create)을 참조하세요.**

**소유한 프로젝트를 공유하려면(AWS RAM 콘솔)**  
AWS RAM 사용 설명서에서 [리소스 공유 생성](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing.html#working-with-sharing-create)을 참조하세요.**

**소유한 프로젝트를 공유하려면(AWS RAM 명령)**  
[create-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/create-resource-share.html) 명령을 사용합니다.

**소유한 프로젝트를 공유하려면(CodeBuild 명령)**<a name="codebuild-command"></a>

[put-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/codebuild/put-resource-policy.html) 명령을 사용합니다.

1. 이름이 `policy.json`인 파일을 만들고 다음으로 복사합니다.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement":[{
       "Effect":"Allow",
       "Action":[
         "codebuild:BatchGetProjects",
         "codebuild:BatchGetBuilds",
         "codebuild:ListBuildsForProject"],
       "Resource":"arn:aws:iam::*:role/Service*"
     }]
   }
   ```

------

1. 프로젝트 ARN 및 식별자로 `policy.json`을 업데이트하여 공유합니다. 다음 예제에서는 123456789012로 식별되는 AWS 계정의 루트 사용자에게 읽기 전용 액세스 권한을 부여합니다.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement":[{
       "Effect":"Allow",
       "Principal":{
         "AWS": [
           "123456789012"
         ]
       },
       "Action":[
         "codebuild:BatchGetProjects",
         "codebuild:BatchGetBuilds",
         "codebuild:ListBuildsForProject"],
       "Resource":"arn:aws:codebuild:us-west-2:123456789012:project/my-project"
     }]
   }
   ```

------

1. [put-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/codebuild/put-resource-policy.html) 명령을 실행합니다.

   ```
   aws codebuild put-resource-policy --resource-arn <project-arn> --policy file://policy.json
   ```

1.  AWS RAM 리소스 공유 ARN을 가져옵니다.

   ```
   aws ram list-resources --resource-owner SELF --resource-arns <project-arn>
   ```

   이렇게 하면 다음과 비슷한 응답이 반환됩니다.

   ```
   {
     "resources": [
       {
         "arn": "<project-arn>",
         "type": "<type>",
         "resourceShareArn": "<resource-share-arn>",
         "creationTime": "<creation-time>",
         "lastUpdatedTime": "<last-update-time>"
       }
     ]
   }
   ```

   응답에서 다음 단계에서 사용할 *<resource-share-arn>* 값을 복사합니다.

1.  AWS RAM [promote-resource-share-created-from-policy](https://docs.aws.amazon.com/cli/latest/reference/ram/promote-resource-share-created-from-policy.html) 명령을 실행합니다.

   ```
   aws ram promote-resource-share-created-from-policy --resource-share-arn <resource-share-arn>
   ```

## 관련 서비스
<a name="project-sharing-related"></a>

프로젝트 공유는 모든 AWS 계정 또는를 통해 AWS 리소스를 공유할 수 있는 서비스AWS RAM인 AWS Resource Access Manager ()와 통합됩니다 AWS Organizations. AWS RAM에서는 리소스와 리소스를 공유할 소비자를 지정하는 *리소스 공유*를 생성하여 리소스를 공유합니다. 소비자는 개별 AWS 계정,의 조직 단위 AWS Organizations또는의 전체 조직일 수 있습니다 AWS Organizations.

자세한 내용은 *[AWS RAM 사용 설명서](https://docs.aws.amazon.com/ram/latest/userguide/)*를 참조하십시오.

# 사용자와 공유된 CodeBuild 프로젝트 액세스
<a name="project-sharing-access-prereqs"></a>

공유 프로젝트에 액세스하려면 소비자의 IAM 역할에 `BatchGetProjects` 권한이 필요합니다. 다음 정책을 해당 IAM 역할에 연결할 수 있습니다.

```
{
    "Effect": "Allow",
    "Resource": [
        "*"
    ],
    "Action": [
        "codebuild:BatchGetProjects"
    ]
}
```

 자세한 내용은 [에 대한 자격 증명 기반 정책 사용 AWS CodeBuild](auth-and-access-control-iam-identity-based-access-control.md) 단원을 참조하십시오.

# 공유 프로젝트의 공유 해제
<a name="project-sharing-unshare"></a>

빌드를 포함하여 공유가 해제된 프로젝트는 소유자만 액세스할 수 있습니다. 프로젝트를 공유 해제하면 이전에 공유한 AWS 계정 또는 사용자가 프로젝트 또는 해당 빌드에 액세스할 수 없습니다.

소유하고 있는 공유 프로젝트의 공유를 해제하려면 리소스 공유에서 제거해야 합니다. AWS CodeBuild 콘솔, AWS RAM 콘솔 또는를 사용하여이 작업을 수행할 수 AWS CLI 있습니다.

**소유한 공유 프로젝트를 공유 해제하려면(AWS RAM 콘솔)**  
*AWS RAM 사용 설명서*에서 [리소스 공유 업데이트](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing.html#working-with-sharing-update)를 참조하세요.

**소유한 공유 프로젝트의 공유를 해제하려면(AWS CLI)**  
[disassociate-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/disassociate-resource-share.html) 명령을 사용합니다.

 **소유한 프로젝트의 공유를 해제하려면(CodeBuild 명령)** 

[delete-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/codebuild/delete-resource-policy.html) 명령을 실행하고 공유를 해제할 프로젝트의 ARN을 지정합니다.

```
aws codebuild delete-resource-policy --resource-arn project-arn
```

# 공유 프로젝트 식별
<a name="project-sharing-identify"></a>

소유자와 소비자는 AWS CLI 를 사용하여 공유 프로젝트를 식별할 수 있습니다.

**AWS 계정 또는 사용자와 공유된 프로젝트를 식별하려면(AWS CLI)**  
[list-shared-projects](https://docs.aws.amazon.com/cli/latest/reference/codebuild/list-shared-projects.html) 명령을 사용하여 공유된 프로젝트를 반환합니다.

# 공유 프로젝트 권한
<a name="project-sharing-perms"></a>

## 소유자에 대한 권한
<a name="project-perms-owner"></a>

프로젝트 소유자는 프로젝트를 편집하고 빌드를 실행하는 데 사용할 수 있습니다.

## 소비자에 대한 권한
<a name="project-perms-consumer"></a>

프로젝트 소비자는 프로젝트와 해당 빌드를 볼 수 있지만 프로젝트를 편집하거나 빌드를 실행하는 데 사용할 수는 없습니다.

# 빌드 프로젝트 태그 지정
<a name="how-to-tag-project"></a>

*태그*는 사용자 또는가 AWS 리소스에 AWS 할당하는 사용자 지정 속성 레이블입니다. 각 AWS 태그에는 두 부분이 있습니다.
+ **태그 키(예: `CostCenter`, `Environment`, `Project` 또는 `Secret`). 태그 키는 대소문자를 구별합니다.
+ **태그 값(예: `111122223333`, `Production` 또는 팀 이름)으로 알려진 선택적 필드. 태그 값을 생략하는 것은 빈 문자열을 사용하는 것과 같습니다. 태그 키처럼 태그 값은 대/소문자를 구별합니다.

태그 키와 태그 값을 합해서 키 값 페어라고 합니다. 프로젝트에서 포함할 수 있는 태그 수와 태그 키 및 값 제한에 대한 자세한 내용은 [태그](limits.md#tag-limits) 단원을 참조하십시오..

태그는 AWS 리소스를 식별하고 구성하는 데 도움이 됩니다. 많은 AWS 서비스가 태그 지정을 지원하므로 다른 서비스의 리소스에 동일한 태그를 할당하여 리소스가 관련이 있음을 나타낼 수 있습니다. 예를 들어 S3 버킷에 할당한 것과 동일한 태그를 CodeBuild 프로젝트에 할당할 수 있습니다. 태그 사용에 대한 자세한 내용은 [태그 지정 모범 사례](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)를 참조하세요.

CodeBuild에서 기본 리소스는 프로젝트와 보고서 그룹입니다. CodeBuild 콘솔, AWS CLI, CodeBuild APIs 또는 AWS SDKs 사용하여 프로젝트의 태그를 추가, 관리 및 제거할 수 있습니다. 태그로 프로젝트를 식별, 구성 및 추적하는 것 외에도 IAM 정책의 태그를 사용하여 프로젝트를 보고, 상호 작용할 수 있는 사용자를 제어할 수 있습니다. 태그 기반 액세스 정책의 예는 [태그를 사용하여 AWS CodeBuild 리소스에 대한 액세스 제어](auth-and-access-control-using-tags.md) 단원을 참조하세요.

**중요**  
예약 용량 기능을 사용할 때 소스 파일, Docker 계층, 빌드스펙에 지정된 캐시된 디렉터리를 포함하여 플릿 인스턴스에 캐시된 데이터를 동일한 계정 내의 다른 프로젝트에서 액세스할 수 있습니다. 이는 설계에 의한 것이며 동일한 계정 내의 프로젝트가 플릿 인스턴스를 공유할 수 있도록 허용합니다.

**Topics**
+ [프로젝트에 태그 추가](how-to-tag-project-add.md)
+ [프로젝트의 태그 보기](how-to-tag-project-list.md)
+ [프로젝트의 태그 편집](how-to-tag-project-update.md)
+ [프로젝트에서 태그 제거](how-to-tag-project-delete.md)

# 프로젝트에 태그 추가
<a name="how-to-tag-project-add"></a>

프로젝트에 태그를 추가하면 AWS 리소스를 식별 및 구성하고 리소스에 대한 액세스를 관리하는 데 도움이 될 수 있습니다. 먼저 프로젝트에 하나 이상의 태그(키-값 페어)를 추가합니다. 프로젝트에 태그 수에 대한 제한이 있음을 알아두십시오. 키 및 값 필드에서 사용할 수 있는 문자에 대한 제한이 있습니다. 자세한 내용은 [태그](limits.md#tag-limits) 단원을 참조하십시오. 태그가 생성된 후 해당 태그를 기준으로 프로젝트에 대한 액세스를 관리하는 IAM 정책을 생성할 수 있습니다. CodeBuild 콘솔 또는를 사용하여 프로젝트에 태그를 AWS CLI 추가할 수 있습니다.

**중요**  
예약 용량 기능을 사용할 때 소스 파일, Docker 계층, 빌드스펙에 지정된 캐시된 디렉터리를 포함하여 플릿 인스턴스에 캐시된 데이터를 동일한 계정 내의 다른 프로젝트에서 액세스할 수 있습니다. 이는 설계에 의한 것이며 동일한 계정 내의 프로젝트가 플릿 인스턴스를 공유할 수 있도록 허용합니다.

프로젝트를 생성할 때 프로젝트에 태그를 추가하는 방법에 대한 자세한 내용은 [프로젝트에 태그 추가(콘솔)](#how-to-tag-project-add-console) 단원을 참조하십시오.

**중요**  
프로젝트에 태그를 추가하기 전에 프로젝트와 같은 리소스에 대한 액세스를 제어하는 태그를 사용할 수도 있는 모든 IAM 정책을 검토하세요. 태그 기반 액세스 정책의 예는 [태그를 사용하여 AWS CodeBuild 리소스에 대한 액세스 제어](auth-and-access-control-using-tags.md) 단원을 참조하세요.

**Topics**
+ [프로젝트에 태그 추가(콘솔)](#how-to-tag-project-add-console)
+ [프로젝트에 태그 추가(AWS CLI)](#how-to-tag-project-add-cli)

## 프로젝트에 태그 추가(콘솔)
<a name="how-to-tag-project-add-console"></a>

CodeBuild 콘솔을 사용하여 CodeBuild 프로젝트에 하나 이상의 태그를 추가할 수 있습니다.

1. [https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/)에서 CodeBuild 콘솔을 엽니다.

1. **빌드 프로젝트**에서 태그를 추가할 프로젝트의 이름을 선택합니다.

1. 탐색 창에서 **설정**을 선택합니다. **빌드 프로젝트 태그**를 선택합니다.

1. 프로젝트에 태그가 추가되지 않은 경우 **태그 추가**를 선택합니다. 또는 **편집**을 선택한 다음 **태그 추가**를 선택합니다.

1. **키**에 태그 이름을 입력합니다. **값**에 태그의 선택적 값을 추가할 수 있습니다.

1. (선택 사항) 다른 태그를 추가하려면 다시 **태그 추가**를 선택합니다.

1. 태그 추가를 마쳤으면 **제출**을 선택합니다.

## 프로젝트에 태그 추가(AWS CLI)
<a name="how-to-tag-project-add-cli"></a>

프로젝트를 생성할 때 프로젝트에 태그를 추가하려면 [빌드 프로젝트 생성(AWS CLI)](create-project.md#create-project-cli) 단원을 참조하십시오. `create-project.json`에서 태그를 추가합니다.

이 단계에서는 사용자가 이미 AWS CLI 의 최신 버전을 설치했거나 현재 버전으로 업데이트했다고 가정합니다. 자세한 정보는 [AWS Command Line Interface설치](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) 섹션을 참조하세요.

성공한 경우 이 명령은 아무 것도 반환하지 않습니다.

# 프로젝트의 태그 보기
<a name="how-to-tag-project-list"></a>

태그는 AWS 리소스를 식별 및 구성하고 리소스에 대한 액세스를 관리하는 데 도움이 될 수 있습니다. 태그 사용에 대한 자세한 내용은 [태그 지정 모범 사례](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf) 백서를 참조하십시오. 태그 기반 액세스 정책의 예는 [태그를 사용하여 AWS CodeBuild 리소스에 대한 액세스 제어](auth-and-access-control-using-tags.md) 단원을 참조하세요.

## 프로젝트의 태그 보기(콘솔)
<a name="how-to-tag-project-list-console"></a>

CodeBuild 콘솔을 사용하여 CodeBuild 프로젝트와 연결된 태그를 볼 수 있습니다.

1. [https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/)에서 CodeBuild 콘솔을 엽니다.

1. **빌드 프로젝트**에서 태그를 보려는 프로젝트의 이름을 선택합니다.

1. 탐색 창에서 **설정**을 선택합니다. **빌드 프로젝트 태그**를 선택합니다.

## 프로젝트의 태그 보기(AWS CLI)
<a name="how-to-tag-project-list-cli"></a>

빌드 프로젝트의 태그를 보려면 다음 명령을 실행합니다. `--names` 파라미터에 대해 프로젝트 이름을 사용합니다.

```
aws codebuild batch-get-projects --names your-project-name
```

성공하면, 이 명령은 다음과 같은 내용을 포함하는 빌드 프로젝트에 대한 JSON 형식의 정보를 반환합니다.

```
{
    "tags": {
        "Status": "Secret",
        "Team": "JanesProject"
    }
}
```

프로젝트에 태그가 없는 경우에는 `tags` 섹션이 비어 있습니다.

```
"tags": []
```

# 프로젝트의 태그 편집
<a name="how-to-tag-project-update"></a>

프로젝트와 연결된 태그에 대한 값을 변경할 수 있습니다. 또한, 키 이름을 변경할 수 있습니다. 이는 현재 태그를 제거하고 새 이름 및 다른 키와 동일한 값을 가진 다른 태그를 추가하는 것과 동일합니다. 키 및 값 필드에서 사용할 수 있는 문자에 대한 제한이 있음을 알아 두세요. 자세한 내용은 [태그](limits.md#tag-limits) 단원을 참조하십시오.

**중요**  
프로젝트의 태그를 편집하면 해당 프로젝트에 대한 액세스에 영향을 줄 수 있습니다. 프로젝트에 대한 태그의 이름(키) 또는 값을 편집하기 전에 프로젝트와 같은 리소스에 대한 액세스를 제어하는 태그의 키 또는 값을 사용할 수도 있는 모든 IAM 정책을 검토하세요. 태그 기반 액세스 정책의 예는 [태그를 사용하여 AWS CodeBuild 리소스에 대한 액세스 제어](auth-and-access-control-using-tags.md) 단원을 참조하세요.

## 프로젝트의 태그 편집(콘솔)
<a name="how-to-tag-project-update-console"></a>

CodeBuild 콘솔을 사용하여 CodeBuild 프로젝트와 연결된 태그를 편집할 수 있습니다.

1. [https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/)에서 CodeBuild 콘솔을 엽니다.

1. **빌드 프로젝트**에서 태그를 편집할 프로젝트의 이름을 선택합니다.

1. 탐색 창에서 **설정**을 선택합니다. **빌드 프로젝트 태그**를 선택합니다.

1. **편집**을 선택합니다.

1. 다음 중 하나를 수행하세요.
   + 태그를 변경하려면 **키**에 새 이름을 입력합니다. 태그 이름을 변경하는 것은 태그를 제거하고 새 키 이름의 새 태그를 추가하는 것과 동일합니다.
   + 태그 값을 변경하려면 새 값을 입력합니다. 값을 어떤 것으로도 변경하지 않으려면 현재 값을 삭제하고 필드를 비워둡니다.

1. 태그 편집을 마쳤으면 **제출**을 선택합니다.

## 프로젝트의 태그 편집(AWS CLI)
<a name="how-to-tag-project-update-cli"></a>

 빌드 프로젝트에서 태그를 추가, 변경 또는 삭제하려면 [빌드 프로젝트 설정 변경(AWS CLI)](change-project.md#change-project-cli) 단원을 참조하십시오. 프로젝트를 업데이트하는 데 사용하는 JSON 형식 데이터의 `tags` 섹션을 업데이트합니다.

# 프로젝트에서 태그 제거
<a name="how-to-tag-project-delete"></a>

프로젝트와 연결된 태그를 하나 이상 제거할 수 있습니다. 태그를 제거해도 해당 태그와 연결된 다른 AWS 리소스에서 태그는 삭제되지 않습니다.

**중요**  
프로젝트의 태그를 제거하면 해당 프로젝트에 대한 액세스에 영향을 줄 수 있습니다. 프로젝트에서 태그를 제거하기 전에 프로젝트와 같은 리소스에 대한 액세스를 제어하는 태그의 키 또는 값을 사용할 수도 있는 모든 IAM 정책을 검토하세요. 태그 기반 액세스 정책의 예는 [태그를 사용하여 AWS CodeBuild 리소스에 대한 액세스 제어](auth-and-access-control-using-tags.md) 단원을 참조하세요.

## 프로젝트에서 태그 제거(콘솔)
<a name="how-to-tag-project-delete-console"></a>

CodeBuild 콘솔을 사용하면 태그와 CodeBuild 프로젝트 간의 연결을 제거할 수 있습니다.

1. [https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/)에서 CodeBuild 콘솔을 엽니다.

1. **빌드 프로젝트**에서 태그를 제거할 프로젝트의 이름을 선택합니다.

1. 탐색 창에서 **설정**을 선택합니다. **빌드 프로젝트 태그**를 선택합니다.

1. **편집**을 선택합니다.

1. 제거할 태그를 찾은 다음 **태그 제거**를 선택합니다.

1. 태그 제거를 마쳤으면 **제출**을 선택합니다.

## 프로젝트에서 태그 제거(AWS CLI)
<a name="how-to-tag-project-delete-cli"></a>

 빌드 프로젝트에서 하나 이상의 태그를 삭제하려면 [빌드 프로젝트 설정 변경(AWS CLI)](change-project.md#change-project-cli) 단원을 참조하십시오. 삭제하려는 태그가 포함되지 않은 업데이트된 태그 목록으로 JSON 형식 데이터의 `tags` 섹션을 업데이트합니다. 모든 태그를 삭제하려면 `tags` 섹션을 다음과 같이 업데이트하십시오.

```
"tags: []"
```

**참고**  
CodeBuild 빌드 프로젝트를 삭제하면 삭제된 빌드 프로젝트에서 모든 태그 연결이 제거됩니다. 프로젝트를 삭제하기 전에 태그를 제거할 필요가 없습니다.

# 에서 실행기 사용 AWS CodeBuild
<a name="runners"></a>

AWS CodeBuild 는 GitHub Actions 실행기, 자체 관리형 GitLab 실행기 및 Buildkite 실행기와의 통합을 지원합니다.

**Topics**
+ [의 자체 호스팅 GitHub Actions 실행기 AWS CodeBuild](action-runner-overview.md)
+ [의 자체 관리형 GitLab 실행기 AWS CodeBuild](gitlab-runner.md)
+ [의 자체 관리형 Buildkite 실행기 AWS CodeBuild](buildkite-runner.md)

# 의 자체 호스팅 GitHub Actions 실행기 AWS CodeBuild
<a name="action-runner-overview"></a>

GitHub Action 워크플로 작업을 처리하기 위해 CodeBuild 컨테이너에서 자체 호스팅 GitHub Action 실행기를 설정하도록 프로젝트를 구성할 수 있습니다. 이는 CodeBuild 프로젝트를 사용하여 웹후크를 설정하고 GitHub 작업 워크플로 YAML을 업데이트하여 CodeBuild 시스템에서 호스팅되는 자체 호스팅 실행기를 사용하여 수행할 수 있습니다.

GitHub Action 작업을 실행하도록 CodeBuild 프로젝트를 구성하는 상위 단계는 다음과 같습니다.

1. 아직 생성하지 않은 경우 개인 액세스 토큰을 생성하거나 OAuth 앱에 연결하여 프로젝트를 GitHub에 연결합니다.

1. CodeBuild 콘솔로 이동하여 웹후크를 사용하여 CodeBuild 프로젝트를 생성하고 웹후크 필터를 설정합니다.

1. GitHub에서 GitHub Action 워크플로 YAML을 업데이트하여 빌드 환경을 구성합니다.

자세한 절차는 [자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md) 섹션을 참조하세요.

이 기능을 사용하면 GitHub Actions 워크플로 작업이 IAM AWS AWS Secrets Manager , 통합 및 Amazon VPC와 같은 기능을 통해 보안 AWS CloudTrail및 편의를 제공하는와 네이티브 통합을 수행할 수 있습니다. ARM 기반 인스턴스를 포함한 최신 인스턴스 유형에 액세스할 수 있습니다.

**Topics**
+ [CodeBuild 호스팅 GitHub Action 실행기 정보](action-runner-questions.md)
+ [자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md)
+ [웹후크 문제 해결](action-runner-troubleshoot-webhook.md)
+ [CodeBuild 호스팅 GitHub Action 실행기에서 지원되는 레이블 재정의](sample-github-action-runners-update-labels.md)
+ [CodeBuild 호스팅 GitHub Action 실행기에서 지원되는 이미지 계산](sample-github-action-runners-update-yaml.images.md)

# CodeBuild 호스팅 GitHub Action 실행기 정보
<a name="action-runner-questions"></a>

다음은 CodeBuild 호스팅 GitHub Action 실행기에 대한 몇 가지 일반적인 질문입니다.

## 레이블에 이미지 및 인스턴스 재정의를 언제 포함해야 합니까?
<a name="action-runner-image-label"></a>

각 GitHub Action 워크플로 작업에 대해 서로 다른 빌드 환경을 지정하기 위해 레이블에 이미지 및 인스턴스 재정의를 포함할 수 있습니다. 이는 여러 CodeBuild 프로젝트 또는 웹후크를 생성할 필요 없이 수행할 수 있습니다. 예를 들어 [워크플로 작업에 매트릭스](https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs)를 사용해야 하는 경우 유용합니다.

```
name: Hello World
on: [push]
jobs:
  Hello-World-Job:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
        image:${{ matrix.os }}
        instance-size:${{ matrix.size }}
    strategy:
      matrix:
        include:
          - os: arm-3.0
            size: small
          - os: linux-5.0
            size: large
    steps:
      - run: echo "Hello World!"
```

**참고**  
`runs-on`에 GitHub Action 컨텍스트가 포함된 레이블이 여러 개 있는 경우 따옴표가 필요할 수 있습니다.

## 이 기능에 CloudFormation 를 사용할 수 있습니까?
<a name="action-runner-cfn"></a>

예, 프로젝트 웹후크에서 GitHub Actions 워크플로 작업 이벤트 필터를 지정하는 필터 그룹을 CloudFormation 템플릿에 포함할 수 있습니다.

```
Triggers:
  Webhook: true
  FilterGroups:
    - - Type: EVENT
        Pattern: WORKFLOW_JOB_QUEUED
```

자세한 내용은 [GitHub Webhook 이벤트 필터링(CloudFormation)](github-webhook-events-cfn.md) 단원을 참조하십시오.

 CloudFormation 템플릿에서 프로젝트 자격 증명을 설정하는 데 도움이 필요한 경우 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [AWS::CodeBuild::SourceCredential](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codebuild-sourcecredential.html)을 참조하세요.

## 이 기능을 사용할 때 암호를 마스킹하려면 어떻게 해야 하나요?
<a name="action-runner-secrets"></a>

기본적으로 로그에 인쇄된 보안 암호는 마스킹되지 않습니다. 보안 암호를 마스킹하려면 다음 구문을 사용할 수 있습니다. `::add-mask::value`. 다음은 YAML에서 이 구문을 사용하는 방법의 예입니다.

```
name: Secret Job
on: [push]
jobs:
  Secret-Job:
    runs-on: codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
    env:
      SECRET_NAME: "secret-name"
    steps:
      - run: echo "::add-mask::$SECRET_NAME"
```

자세한 내용은 GitHub의 [로그에서 값 마스킹](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#masking-a-value-in-a-log)을 참조하세요.

## 단일 프로젝트 내의 여러 리포지토리에서 GitHub Action 웹후크 이벤트를 수신할 수 있나요?
<a name="action-runner-webhooks"></a>

CodeBuild는 지정된 조직 또는 엔터프라이즈에서 이벤트를 수신하는 조직 및 글로벌 수준 웹후크를 지원합니다. 자세한 내용은 [GitHub 글로벌 및 조직 웹후크](github-global-organization-webhook.md) 단원을 참조하십시오.

## CodeBuild 호스팅 GitHub Action 실행기 사용을 지원하는 리전은 무엇입니까?
<a name="action-runner-hosted-regions"></a>

CodeBuild 호스팅 GitHub Action 실행기는 모든 CodeBuild 리전에서 지원됩니다. CodeBuild를 사용할 수 AWS 리전 있는 위치에 대한 자세한 내용은 [AWS 리전별 서비스를](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) 참조하세요.

## CodeBuild 호스팅 GitHub Action 실행기 사용을 지원하는 플랫폼은 무엇입니까?
<a name="action-runner-platform"></a>

CodeBuild 호스팅 GitHub Action 실행기는 Amazon EC2와 [AWS Lambda](lambda.md) 컴퓨팅 모두에서 지원됩니다. Amazon Linux 2, Amazon Linux 2023, Ubuntu 및 Windows Server Core 2019 플랫폼을 사용할 수 있습니다. 자세한 내용은 [EC2 컴퓨팅 이미지](ec2-compute-images.md) 및 [Lambda 컴퓨팅 이미지](lambda-compute-images.md) 섹션을 참조하세요.

# 자습서: CodeBuild 호스팅 GitHub Action 실행기 구성
<a name="action-runner"></a>

이 자습서에서는 GitHub Action 작업을 실행하도록 CodeBuild 프로젝트를 구성하는 방법을 보여줍니다. GitHub Action과 CodeBuild를 함께 사용하는 방법에 대한 자세한 내용은 [자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](#action-runner) 섹션을 참조하세요.<a name="sample-github-action-runners-prerequisites"></a>

이 자습서를 완료하려면 먼저 다음을 수행해야 합니다.
+ 개인 액세스 토큰, Secrets Manager 보안 암호, OAuth 앱 또는 GitHub 앱으로 연결합니다. OAuth 앱에 연결하려면 CodeBuild 콘솔을 사용하여 연결해야 합니다. 개인 액세스 토큰을 생성하려는 경우 CodeBuild 콘솔을 사용하거나 [ImportSourceCredentials API를](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ImportSourceCredentials.html) 사용할 수 있습니다. 자세한 지침은 [CodeBuild의 GitHub 및 GitHub Enterprise Server 액세스](access-tokens-github-overview.md) 섹션을 참조하세요.
+ CodeBuild를 GitHub 계정에 연결합니다. 이렇게 하려면 다음 중 하나를 수행할 수 있습니다.
  + 콘솔에서 GitHub를 소스 공급자로 추가할 수 있습니다. 개인 액세스 토큰, Secrets Manager 보안 암호, OAuth 앱 또는 GitHub 앱으로 연결할 수 있습니다. 지침은 [CodeBuild의 GitHub 및 GitHub Enterprise Server 액세스](access-tokens-github-overview.md) 섹션을 참조하세요.
  + [ImportSourceCredentials API](https://docs.aws.amazon.com/cli/latest/reference/codebuild/import-source-credentials.html)를 통해 GitHub 자격 증명을 가져올 수 있습니다. 이는 개인 액세스 토큰으로만 수행할 수 있습니다. OAuth 앱을 사용하여 연결하는 경우 콘솔을 사용하여 대신 연결해야 합니다. 지침은 [액세스 토큰을 사용하여 GitHub에 연결(CLI)](access-tokens-github.md#access-tokens-github-cli) 섹션을 참조하세요.
**참고**  
이는 계정에 대해 GitHub에 연결하지 않은 경우에만 수행하면 됩니다.

## 1단계: 웹후크를 사용하여 CodeBuild 프로젝트 생성
<a name="sample-github-action-runners-create-project"></a>

이 단계에서는 웹후크를 사용하여 CodeBuild 프로젝트를 생성하고 GitHub 콘솔에서 검토합니다. 소스 공급자로 GitHub Enterprise를 선택할 수도 있습니다. GitHub Enterprise 내에서 웹후크를 생성하는 방법에 대한 자세한 내용은 [GitHub 수동 웹후크](github-manual-webhook.md) 섹션을 참조하세요.

**웹후크를 사용하여 CodeBuild 프로젝트를 생성하려면**

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.

1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.

1. **프로젝트 유형**에서 **Runner 프로젝트를** 선택합니다.

   **러너**에서:

   1. **Runner 공급자**에서 **GitHub**를 선택합니다.

   1. **러너 위치에서** **리포지토리**를 선택합니다.

   1. 리포지토리 아래의 **리포지토리** URL에서 **https://github.com/user-name/repository-name** 선택합니다.
**참고**  
기본적으로 프로젝트는 단일 리포지토리에 대한 `WORKFLOW_JOB_QUEUED` 이벤트만 수신합니다. 조직 또는 엔터프라이즈 내의 모든 리포지토리에 대한 이벤트를 수신하려면 [GitHub 글로벌 및 조직 웹후크](github-global-organization-webhook.md) 섹션을 참조하세요.

1. 
   +  **환경**에서 다음과 같이 합니다.
     + 지원되는 **환경 이미지**와 **컴퓨팅**을 선택합니다. GitHub Action 워크플로 YAML의 레이블을 사용하여 이미지 및 인스턴스 설정을 재정의할 수 있는 옵션이 있습니다. 자세한 내용은 [2단계: GitHub Action 워크플로 YAML 업데이트](#sample-github-action-runners-update-yaml) 섹션을 참조하세요.
   +  **Buildspec**에서 다음과 같이 합니다.
     + `buildspec-override:true`가 레이블로 추가되지 않는 한 buildspec은 무시됩니다. 대신 CodeBuild는 자체 호스팅 실행기를 설정하는 명령을 사용하도록 재정의합니다.

1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다.

1. `https://github.com/user-name/repository-name/settings/hooks`에서 GitHub 콘솔을 열어 웹후크가 생성되었고 **워크플로 작업** 이벤트를 전달할 수 있는지 확인합니다.

## 2단계: GitHub Action 워크플로 YAML 업데이트
<a name="sample-github-action-runners-update-yaml"></a>

이 단계에서는 [https://github.com/](https://github.com/)에서 GitHub Action 워크플로 YAML 파일을 업데이트하여 빌드 환경을 구성하고 CodeBuild에서 GitHub Action 자체 호스팅 실행기를 사용합니다. 자세한 내용은 [자체 호스팅 실행기에서 레이블 사용](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-labels-with-self-hosted-runners) 및 [CodeBuild 호스팅 GitHub Action 실행기에서 지원되는 레이블 재정의](sample-github-action-runners-update-labels.md) 섹션을 참조하세요.

### GitHub Action 워크플로 YAML 업데이트
<a name="sample-github-action-runners-update-yaml.setup"></a>

GitHub Action 워크플로 YAML의 [https://github.com/](https://github.com/) 설정으로 이동하여 [https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-labels-with-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-labels-with-self-hosted-runners)을 업데이트하여 빌드 환경을 구성합니다. 이렇게 하려면 다음 중 하나를 수행할 수 있습니다.
+ 프로젝트 이름과 실행 ID를 지정할 수 있습니다. 이 경우 빌드는 컴퓨팅, 이미지, 이미지 버전 및 인스턴스 크기에 대한 기존 프로젝트 구성을 사용합니다. 프로젝트 이름은 GitHub Action 작업의 AWS관련 설정을 특정 CodeBuild 프로젝트에 연결하는 데 필요합니다. YAML에 프로젝트 이름을 포함하면 CodeBuild가 올바른 프로젝트 설정으로 작업을 호출할 수 있습니다. CodeBuild는 실행 ID를 제공하여 빌드를 특정 워크플로 실행에 매핑하고 워크플로 실행이 취소되면 빌드를 중지합니다. 자세한 내용은 [`github` 컨텍스트](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context)를 참조하세요.

  ```
  runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}
  ```
**참고**  
*<project-name>*이 이전 단계에서 생성한 프로젝트의 이름과 일치하는지 확인합니다. 일치하지 않으면 CodeBuild는 웹후크를 처리하지 않고 GitHub Action 워크플로가 중단될 수 있습니다.

  다음은 GitHub Action 워크플로 YAML의 예입니다.

  ```
  name: Hello World
  on: [push]
  jobs:
    Hello-World-Job:
      runs-on:
        - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
      steps:
        - run: echo "Hello World!"
  ```
+ 레이블에서 이미지 및 컴퓨팅 유형을 재정의할 수도 있습니다. 큐레이션된 이미지 목록은 섹션을 참조[CodeBuild 호스팅 GitHub Action 실행기에서 지원되는 이미지 계산](sample-github-action-runners-update-yaml.images.md)하세요. 사용자 지정 이미지 사용은 섹션을 참조하세요[CodeBuild 호스팅 GitHub Action 실행기에서 지원되는 레이블 재정의](sample-github-action-runners-update-labels.md). 레이블의 컴퓨팅 유형 및 이미지가 프로젝트의 환경 설정을 재정의합니다. CodeBuild EC2 또는 Lambda 컴퓨팅 빌드의 환경 설정을 재정의하려면 다음 구문을 사용합니다.

  ```
  runs-on:
    - codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}
      image:<environment-type>-<image-identifier>
      instance-size:<instance-size>
  ```

  다음은 GitHub Action 워크플로 YAML의 예입니다.

  ```
  name: Hello World
  on: [push]
  jobs:
    Hello-World-Job:
      runs-on:
        - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
          image:arm-3.0
          instance-size:small
      steps:
        - run: echo "Hello World!"
  ```
+ 레이블에서 빌드에 사용되는 플릿을 재정의할 수 있습니다. 이렇게 하면 지정된 플릿을 사용하도록 프로젝트에 구성된 플릿 설정이 재정의됩니다. 자세한 내용은 [예약 용량 플릿에서 빌드 실행](fleets.md) 단원을 참조하십시오. Amazon EC2 컴퓨팅 빌드의 플릿 설정을 재정의하려면 다음 구문을 사용합니다.

  ```
  runs-on:
    - codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}
      fleet:<fleet-name>
  ```

  빌드에 사용되는 플릿과 이미지를 모두 재정의하려면 다음 구문을 사용합니다.

  ```
  runs-on:
    - codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}
      fleet:<fleet-name>
      image:<environment-type>-<image-identifier>
  ```

  다음은 GitHub Action 워크플로 YAML의 예입니다.

  ```
  name: Hello World
  on: [push]
  jobs:
    Hello-World-Job:
      runs-on:
        - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
          fleet:myFleet
          image:arm-3.0
      steps:
        - run: echo "Hello World!"
  ```
+ 사용자 지정 이미지에서 GitHub Action 작업을 실행하려면 CodeBuild 프로젝트에서 사용자 지정 이미지를 구성하고 이미지 재정의 레이블을 제공하지 않아도 됩니다. CodeBuild는 이미지 재정의 레이블이 제공되지 않은 경우 프로젝트에 구성된 이미지를 사용합니다.
+ 선택적으로 CodeBuild가 지원하는 레이블 이외의 레이블을 제공할 수 있습니다. 이러한 레이블은 빌드의 속성을 재정의할 목적으로 무시되지만 웹후크 요청에 실패하지는 않습니다. 예를 들어 레이블로 `testLabel`을 추가해도 레이블은 빌드 실행을 방해하지 않습니다.

**참고**  
CodeBuild 환경에서 GitHub 호스팅 실행기가 제공하는 종속 항목을 사용할 수 없는 경우 워크플로 실행에서 GitHub Action을 사용하여 종속 항목을 설치할 수 있습니다. 예를 들어 [https://github.com/actions/setup-python](https://github.com/actions/setup-python) 작업을 사용하여 빌드 환경에 Python을 설치할 수 있습니다.

### buildspec 명령 실행 INSTALL, PRE\$1BUILD 및 POST\$1BUILD 단계
<a name="sample-github-action-runners-update-yaml.buildspec"></a>

기본적으로 CodeBuild는 자체 호스팅 GitHub Action 빌드를 실행할 때 모든 buildspec 명령을 무시합니다. 빌드 중에 buildspec 명령을 실행하려면 `buildspec-override:true`를 레이블에 접미사로 추가할 수 있습니다.

```
runs-on:
  - codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}
    buildspec-override:true
```

이 명령을 사용하면 CodeBuild는 컨테이너의 기본 소스 폴더에 `actions-runner`라는 폴더를 생성합니다. `BUILD` 단계 중에 GitHub Action 실행기가 시작되면 실행기가 `actions-runner` 디렉터리에서 실행됩니다.

자체 호스팅 GitHub Action 빌드에서 buildspec 재정의를 사용하는 경우 몇 가지 제한이 있습니다.
+ CodeBuild는 `BUILD` 단계에서 자체 호스팅된 실행기가 실행되므로 `BUILD` 단계 중에 buildspec 명령을 실행하지 않습니다.
+ CodeBuild는 `DOWNLOAD_SOURCE` 단계 중에 기본 또는 보조 소스를 다운로드하지 않습니다. buildspec 파일이 구성된 경우 해당 파일만 프로젝트의 기본 소스에서 다운로드됩니다.
+ `PRE_BUILD` 또는 `INSTALL` 단계에서 빌드 명령이 실패하면 CodeBuild는 자체 호스팅 실행기를 시작하지 않으며 GitHub Action 워크플로 작업을 수동으로 취소해야 합니다.
+ CodeBuild는 만료 시간이 1시간인 `DOWNLOAD_SOURCE` 단계 중에 실행기 토큰을 가져옵니다. `PRE_BUILD` 또는 `INSTALL` 단계가 1시간을 초과하면 GitHub 자체 호스팅 실행기가 시작되기 전에 실행기 토큰이 만료될 수 있습니다.

## 3단계: 결과 검토
<a name="sample-github-action-runners-verify"></a>

GitHub Action 워크플로 실행이 발생할 때마다 CodeBuild는 웹후크를 통해 워크플로 작업 이벤트를 수신합니다. 워크플로의 각 작업에 대해 CodeBuild는 임시 GitHub Action 실행기를 실행하기 위한 빌드를 시작합니다. 실행기는 단일 워크플로 작업을 실행할 책임이 있습니다. 작업이 완료되면 실행기와 관련 빌드 프로세스가 즉시 종료됩니다.

워크플로 작업 로그를 보려면 GitHub에서 리포지토리로 이동하여 **작업**을 선택하고 원하는 워크플로를 선택한 다음 로그를 검토하려는 특정 **작업**을 선택합니다.

CodeBuild에서 자체 호스팅된 실행기가 작업을 픽업할 때까지 기다리는 동안 로그에서 요청된 레이블을 검토할 수 있습니다.

![\[작업의 로그 로드.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/hello-world-loading.png)


작업이 완료되면 작업 로그를 볼 수 있습니다.

![\[작업의 로그입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/hello-world-log.png)


## GitHub Actions 실행기 구성 옵션
<a name="sample-github-action-runners-config"></a>

프로젝트 구성에서 다음 환경 변수를 지정하여 자체 호스팅 러너의 설정 구성을 수정할 수 있습니다.

`CODEBUILD_CONFIG_GITHUB_ACTIONS_ORG_REGISTRATION_NAME`  
CodeBuild는 자체 호스팅 러너를이 환경 변수의 값으로 지정된 조직 이름에 등록합니다. 조직 수준에서 러너를 등록하는 방법과 필요한 권한에 대한 자세한 내용은 [ 조직의 just-in-time 러너에 대한 구성 생성을 참조하세요](https://docs.github.com/en/rest/actions/self-hosted-runners?apiVersion=2022-11-28#create-configuration-for-a-just-in-time-runner-for-an-organization).

`CODEBUILD_CONFIG_GITHUB_ACTIONS_ENTERPRISE_REGISTRATION_NAME`  
CodeBuild는 자체 호스팅 러너를이 환경 변수의 값으로 지정된 엔터프라이즈 이름에 등록합니다. 엔터프라이즈 수준에서 러너를 등록하는 방법과 필요한 권한에 대한 자세한 내용은 [ 엔터프라이즈just-in-time 러너에 대한 구성 생성을 참조하세요](https://docs.github.com/en/enterprise-server/rest/actions/self-hosted-runners?apiVersion=2022-11-28#create-configuration-for-a-just-in-time-runner-for-an-enterprise).  
엔터프라이즈 러너는 기본적으로 조직 리포지토리에서 사용할 수 없습니다. 자체 호스팅 러너가 워크플로 작업을 픽업하려면 러너 그룹 액세스 설정을 구성해야 할 수 있습니다. 자세한 내용은 [ 엔터프라이즈 러너를 리포지토리에 사용할 수 있도록 만들기](https://docs.github.com/en/enterprise-server/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners#making-enterprise-runners-available-to-repositories)를 참조하세요.

`CODEBUILD_CONFIG_GITHUB_ACTIONS_RUNNER_GROUP_ID`  
CodeBuild는이 환경 변수의 값으로 저장된 정수 실행기 그룹 ID에 자체 호스팅 실행기를 등록합니다. 기본적으로이 값은 1입니다. 자체 호스팅 러너 그룹에 대한 자세한 내용은 [ 그룹을 사용하여 자체 호스팅 러너에 대한 액세스 관리를 참조하세요](https://docs.github.com/en/rest/actions/self-hosted-runners?apiVersion=2022-11-28#create-configuration-for-a-just-in-time-runner-for-an-organization).

`CODEBUILD_CONFIG_GITHUB_ACTIONS_ORG_REGISTRATION_NAME`  
GitHub Actions 워크플로 YAML 파일을 사용하여 조직 수준 실행기 등록을 구성하려면 다음 구문을 사용할 수 있습니다.  

```
name: Hello World
on: [push]
jobs:
  Hello-World-Job:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
        organization-registration-name:myOrganization
    steps:
      - run: echo "Hello World!"
```

`CODEBUILD_CONFIG_GITHUB_ACTIONS_ENTERPRISE_REGISTRATION_NAME`  
GitHub Actions 워크플로 YAML 파일을 사용하여 엔터프라이즈 수준 실행기 등록을 구성하려면 다음 구문을 사용할 수 있습니다.  

```
name: Hello World
on: [push]
jobs:
  Hello-World-Job:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
        enterprise-registration-name:myEnterprise
    steps:
      - run: echo "Hello World!"
```

`CODEBUILD_CONFIG_GITHUB_ACTIONS_RUNNER_GROUP_ID`  
GitHub Actions 워크플로 YAML 파일을 사용하여 특정 러너 그룹 ID에 러너 등록을 구성하려면 다음 구문을 사용할 수 있습니다.  

```
name: Hello World
on: [push]
jobs:
  Hello-World-Job:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
        registration-group-id:3
    steps:
      - run: echo "Hello World!"
```

## GitHub Action 웹후크 이벤트 필터링(CloudFormation)
<a name="sample-github-action-runners-webhooks-cfn"></a>

 CloudFormation 템플릿의 다음 YAML 형식 부분은 빌드가 true로 평가될 때 빌드를 트리거하는 필터 그룹을 생성합니다. 다음 필터 그룹은 정규식 `\[CI-CodeBuild\]`와 일치하는 워크플로 이름을 가진 GitHub Action 워크플로 작업 요청을 지정합니다.

```
CodeBuildProject:
  Type: AWS::CodeBuild::Project
  Properties:
    Name: MyProject
    ServiceRole: service-role
    Artifacts:
      Type: NO_ARTIFACTS
    Environment:
      Type: LINUX_CONTAINER
      ComputeType: BUILD_GENERAL1_SMALL
      Image: aws/codebuild/standard:5.0
    Source:
      Type: GITHUB
      Location: CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION
    Triggers:
      Webhook: true
      ScopeConfiguration:
        Name: organization-name
        Scope: GITHUB_ORGANIZATION
      FilterGroups:
        - - Type: EVENT
            Pattern: WORKFLOW_JOB_QUEUED
          - Type: WORKFLOW_NAME
            Pattern: \[CI-CodeBuild\]
```

## GitHub Action 웹후크 이벤트 필터링(AWS CDK)
<a name="sample-github-action-runners-webhooks-cdk"></a>

다음 AWS CDK 템플릿은 빌드가 true로 평가될 때 빌드를 트리거하는 필터 그룹을 생성합니다. 다음 필터 그룹은 GitHub Action 워크플로 작업 요청을 지정합니다.

```
import { aws_codebuild as codebuild } from 'aws-cdk-lib';
import {EventAction, FilterGroup} from "aws-cdk-lib/aws-codebuild";

const source = codebuild.Source.gitHub({
      owner: 'owner',
      repo: 'repo',
      webhook: true,
      webhookFilters: [FilterGroup.inEventOf(EventAction.WORKFLOW_JOB_QUEUED)],
    })
```

## GitHub Action 웹후크 이벤트 필터링(Terraform)
<a name="sample-github-action-runners-webhooks-terraform"></a>

다음 Terraform 템플릿은 빌드가 true로 평가될 때 빌드를 트리거하는 필터 그룹을 생성합니다. 다음 필터 그룹은 GitHub Action 워크플로 작업 요청을 지정합니다.

```
resource "aws_codebuild_webhook" "example" {
  project_name = aws_codebuild_project.example.name
  build_type   = "BUILD"
  filter_group {
    filter {
      type    = "EVENT"
      pattern = "WORKFLOW_JOB_QUEUED"
    }
  }
}
```

## GitHub Action 웹후크 이벤트 필터링(AWS CLI)
<a name="sample-github-action-runners-webhooks-cli"></a>

다음 AWS CLI 명령은 빌드가 true로 평가될 때 빌드를 트리거하는 GitHub Actions 워크플로 작업 요청 필터 그룹을 사용하여 자체 호스팅 GitHub Actions 실행기 프로젝트를 생성합니다. GitHub 

```
aws codebuild create-project \
--name <project name> \
--source "{\"type\":\"GITHUB\",\"location\":\"<repository location>\",\"buildspec\":\"\"}" \
--artifacts {"\"type\":\"NO_ARTIFACTS\""} \
--environment "{\"type\": \"LINUX_CONTAINER\",\"image\": \"aws/codebuild/amazonlinux-x86_64-standard:5.0\",\"computeType\": \"BUILD_GENERAL1_MEDIUM\"}" \
--service-role "<service role ARN>"
```

```
aws codebuild create-webhook \
--project-name <project name> \
--filter-groups "[[{\"type\":\"EVENT\",\"pattern\":\"WORKFLOW_JOB_QUEUED\"}]]"
```

# 웹후크 문제 해결
<a name="action-runner-troubleshoot-webhook"></a>

**문제: **[자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md)에서 설정한 웹후크가 작동하지 않거나 GitHub에서 워크플로 작업이 중단되고 있습니다.

**가능한 원인: **
+ Webhook **워크플로 작업** 이벤트가 빌드를 트리거하지 못할 수 있습니다. **응답** 로그를 검토하여 응답 또는 오류 메시지를 확인합니다.
+ 레이블 구성으로 인해 작업이 잘못된 러너 에이전트에 할당되고 있습니다. 이 문제는 단일 워크플로 실행 내 작업 중 하나에 다른 작업보다 레이블이 적은 경우에 발생할 수 있습니다. 예를 들어 동일한 워크플로 실행에 다음 레이블이 있는 작업이 두 개 있는 경우:
  + **작업 1**: `codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}`
  + **작업 2**: `codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}`, `instance-size:medium` 

  자체 호스팅된 GitHub Actions 작업을 라우팅할 때 GitHub는 모든 작업의 지정된 레이블이 있는 러너로 작업을 라우팅합니다. 이 동작은 **작업 1** 또는 작업 **2**에 대해 생성된 러너가 **작업 1**을 선택할 수 있지만 **추가 레이블이 있으므로 작업 2**에 대해 생성된 러너만 **작업 2**를 선택할 수 있음을 의미합니다. **작업 2**용으로 생성된 실행기가 **작업 **1을 선택하면 **작업 ****1 실행기에 레이블이 없으므로 작업 **2가 중단됩니다. `instance-size:medium` 

**권장 솔루션: **

동일한 워크플로 실행 내에서 여러 작업을 생성할 때 각 작업에 대해 동일한 수의 레이블 재정의를 사용하거나 `job1` 또는와 같은 사용자 지정 레이블을 각 작업에 할당합니다`job2`.

오류가 지속되면 다음 지침에 따라 문제를 디버깅합니다.

1. `https://github.com/user-name/repository-name/settings/hooks`에서 GitHub 콘솔을 열어 리포지토리의 웹후크 설정을 확인합니다. 이 페이지에는 리포지토리를 위해 생성된 웹후크가 표시됩니다.

1. **편집**을 선택하고 웹후크가 **워크플로 작업** 이벤트를 전달하도록 활성화되어 있는지 확인합니다.  
![\[워크플로 작업 이벤트는 웹후크에서 활성화됩니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-actions-workflow-jobs.png)

1.  **최근 전송** 탭으로 이동하여 해당 `workflow_job.queued` 이벤트를 찾아 이벤트를 확장합니다.

1.  **페이로드**의 **레이블** 필드를 검토하고 예상대로인지 확인합니다.

1.  마지막으로 **응답** 탭을 검토합니다. 응답 탭에는 CodeBuild에서 반환된 응답 또는 오류 메시지가 포함되어 있기 때문입니다.  
![\[CodeBuild에서 반환된 응답 또는 오류 메시지입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-actions-workflow-jobs-response.png)

1.  또는 GitHub의 API를 사용하여 웹후크 실패를 디버깅할 수 있습니다. [리포지토리 웹후크 API의 목록 전송](https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#list-deliveries-for-a-repository-webhook)을 사용하여 웹후크의 최근 전송을 볼 수 있습니다.

   ```
   gh api \
     -H "Accept: application/vnd.github+json" \
     -H "X-GitHub-Api-Version: 2022-11-28" \
     /repos/owner/repo/hooks/hook-id/deliveries
   ```

    디버깅하고 전송 ID를 기록하려는 웹후크 전송을 찾은 후 [리포지토리 웹후크에 대한 전송 가져오기](https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#get-a-delivery-for-a-repository-webhook) API를 사용할 수 있습니다. 웹후크의 전송 페이로드에 대한 CodeBuild의 응답은 `response` 섹션에서 확인할 수 있습니다.

   ```
   gh api \
     -H "Accept: application/vnd.github+json" \
     -H "X-GitHub-Api-Version: 2022-11-28" \
     /repos/owner/repo/hooks/hook-id/deliveries/delivery-id
   ```

**문제:** [배포 보호](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments) 규칙이 활성화된 GitHub 작업은 배포가 승인되기 전에 CodeBuild 내에 빌드됩니다.

**가능한 원인:** CodeBuild는가 승인되었는지 확인하기 위해 GitHub Actions 작업과 연결된 배포 및 환경을 가져옵니다. CodeBuild가 배포 또는 환경을 가져오지 못하면 CodeBuild 빌드가 조기에 트리거될 수 있습니다.

**권장 솔루션:** CodeBuild 프로젝트와 연결된 자격 증명에 GitHub 내의 배포 및 작업에 대한 읽기 권한이 있는지 확인합니다.

# CodeBuild 호스팅 GitHub Action 실행기에서 지원되는 레이블 재정의
<a name="sample-github-action-runners-update-labels"></a>

GitHub Action 워크플로 YAML에서 자체 호스팅 실행기 빌드를 수정하는 다양한 레이블 재정의를 제공할 수 있습니다. CodeBuild에서 인식하지 못하는 빌드는 무시되지만 웹후크 요청에 실패하지는 않습니다. 예를 들어 다음 워크플로 YAML에는 이미지, 인스턴스 크기, 플릿 및 buildspec에 대한 재정의를 포함합니다.

```
name: Hello World
on: [push]
jobs:
  Hello-World-Job:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
        image:${{ matrix.os }}
        instance-size:${{ matrix.size }}
        fleet:myFleet
        buildspec-override:true
    strategy:
      matrix:
        include:
          - os: arm-3.0
            size: small
          - os: linux-5.0
            size: large
    steps:
      - run: echo "Hello World!"
```

**참고**  
워크플로 작업이 GitHub에서 중단되는 경우 [웹후크 문제 해결](action-runner-troubleshoot-webhook.md) 및 [ 사용자 지정 레이블을 사용하여 작업 라우팅](https://docs.github.com/en/enterprise-server@3.12/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow?learn=hosting_your_own_runners&learnProduct=actions#using-custom-labels-to-route-jobs)을 참조하세요.

`codebuild-<project-name>-${{github.run_id}}-${{github.run_attempt}}`(필수)
+ 예시: `codebuild-fake-project-${{ github.run_id }}-${{ github.run_attempt }}`
+ 모든 GitHub Action 워크플로 YAML에 필요합니다. *<project name>*은 자체 호스팅 실행기 웹후크가 구성된 프로젝트의 이름과 같아야 합니다.

`image:<environment-type>-<image-identifier>`
+ 예시: `image:arm-3.0`
+ 큐레이션된 이미지로 자체 호스팅 러너 빌드를 시작할 때 사용되는 이미지 및 환경 유형을 재정의합니다. 지원되는 값에 대한 자세한 내용은 [CodeBuild 호스팅 GitHub Action 실행기에서 지원되는 이미지 계산](sample-github-action-runners-update-yaml.images.md) 섹션을 참조하세요.
  + 사용자 지정 이미지와 함께 사용되는 이미지 및 환경 유형을 재정의하려면 `image:custom-<environment-type>-<custom-image-identifier>`
  + 예시: `image:custom-arm-public.ecr.aws/codebuild/amazonlinux-aarch64-standard:3.0`
**참고**  
사용자 지정 이미지가 프라이빗 레지스트리에 있는 경우 섹션을 참조하세요[자체 호스팅 러너에 대한 프라이빗 레지스트리 자격 증명 구성](private-registry-sample-configure-runners.md).

`instance-size:<instance-size>`
+ 예시: `instance-size:medium`
+ 자체 호스팅 실행기 빌드를 시작할 때 사용되는 인스턴스 유형을 재정의합니다. 지원되는 값에 대한 자세한 내용은 [CodeBuild 호스팅 GitHub Action 실행기에서 지원되는 이미지 계산](sample-github-action-runners-update-yaml.images.md) 섹션을 참조하세요.

`fleet:<fleet-name>`
+ 예시: `fleet:myFleet`
+ 지정된 플릿을 사용하도록 프로젝트에 구성된 플릿 설정을 재정의합니다. 자세한 내용은 [예약 용량 플릿에서 빌드 실행](fleets.md) 단원을 참조하십시오.

`buildspec-override:<boolean>`
+ 예시: `buildspec-override:true`
+ `true`로 설정된 경우 빌드가 `INSTALL`, `PRE_BUILD` 및 `POST_BUILD` 단계에서 buildspec 명령을 실행하도록 허용합니다.

## 단일 레이블 재정의(레거시)
<a name="sample-github-action-runners-update-single-labels"></a>

CodeBuild를 사용하면 다음을 사용하여 단일 레이블에 여러 재정의를 제공할 수 있습니다.
+ Amazon EC2/Lambda 컴퓨팅 빌드의 환경 설정을 재정의하려면 다음 구문을 사용합니다.

  ```
  runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-<environment-type>-<image-identifier>-<instance-size>
  ```
+ Amazon EC2 컴퓨팅 빌드에 대한 플릿 설정을 재정의하려면 다음 구문을 사용합니다.

  ```
  runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-fleet-<fleet-name>
  ```
+ 빌드에 사용되는 플릿과 이미지를 모두 재정의하려면 다음 구문을 사용합니다.

  ```
  runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-image-<image-version>-fleet-<fleet-name>
  ```
+ 빌드 중에 buildspec 명령을 실행하려면 `-with-buildspec`를 레이블에 접미사로 추가할 수 있습니다.

  ```
  runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-<image>-<image-version>-<instance-size>-with-buildspec
  ```
+ 선택적으로 이미지를 재정의하지 않고 인스턴스 크기 재정의를 제공할 수 있습니다. Amazon EC2 빌드의 경우 환경 유형과 이미지 식별자를 모두 제외할 수 있습니다. Lambda 빌드의 경우 이미지 식별자를 제외할 수 있습니다.

# CodeBuild 호스팅 GitHub Action 실행기에서 지원되는 이미지 계산
<a name="sample-github-action-runners-update-yaml.images"></a>

[자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md)에서 구성한 레이블에서 처음 세 열의 값을 사용하여 Amazon EC2 환경 설정을 재정의할 수 있습니다. CodeBuild는 다음과 같은 Amazon EC2 컴퓨팅 이미지를 제공합니다. 해당 내용은 다음을 참조하세요.

<a name="build-env-ref.supported-images"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/sample-github-action-runners-update-yaml.images.html)

또한 다음 값을 사용하여 Lambda 환경 설정을 재정의할 수 있습니다. CodeBuild Lambda 컴퓨팅에 대한 자세한 내용은 [AWS Lambda 컴퓨팅 기반 빌드 실행](lambda.md) 섹션을 참조하세요. CodeBuild는 다음 Lambda 컴퓨팅 이미지를 지원합니다.

<a name="lambda.supported-images"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/sample-github-action-runners-update-yaml.images.html)

자세한 내용은 [빌드 환경 컴퓨팅 모드 및 유형](build-env-ref-compute-types.md) 및 [CodeBuild가 제공하는 도커 이미지](build-env-ref-available.md) 섹션을 참조하세요.

# 의 자체 관리형 GitLab 실행기 AWS CodeBuild
<a name="gitlab-runner"></a>

GitLab은 CI/CD 파이프라인에서 GitLab 작업을 실행하는 두 가지 실행 모드를 제공합니다. 한 가지 모드는 GitLab에서 관리하고 GitLab과 완전히 통합된 GitLab 호스팅 실행기입니다. 다른 모드는 자체 관리형 실행기로, GitLab CI/CD 파이프라인에서 작업을 실행할 수 있도록 사용자 지정 환경을 가져올 수 있습니다.

GitLab CI/CD 파이프라인 작업을 실행하도록 CodeBuild 프로젝트를 구성하는 상위 단계는 다음과 같습니다.

1. 아직 생성하지 않은 경우 개인 OAuth 앱에 연결하여 프로젝트를 GitLab에 연결합니다.

1. CodeBuild 콘솔로 이동하여 웹후크를 사용하여 CodeBuild 프로젝트를 생성하고 웹후크 필터를 설정합니다.

1. GitLab에서 GitLab CI/CD 파이프라인 YAML을 업데이트하여 빌드 환경을 구성합니다.

자세한 절차는 [자습서: CodeBuild 호스팅 GitLab 실행기 구성](sample-gitlab-runners.md) 섹션을 참조하세요.

이 기능을 사용하면 GitLab CI/CD 파이프라인 작업이 AWS와 네이티브 통합될 수 있으며, IAM, AWS CloudTrail및 Amazon VPC와 같은 기능을 통해 보안 및 편의성을 제공합니다. ARM 기반 인스턴스를 포함한 최신 인스턴스 유형에 액세스할 수 있습니다.

**Topics**
+ [CodeBuild 호스팅 GitLab 실행기 정보](gitlab-runner-questions.md)
+ [자습서: CodeBuild 호스팅 GitLab 실행기 구성](sample-gitlab-runners.md)
+ [CodeBuild 호스팅 GitLab 실행기에서 지원되는 레이블 재정의](gitlab-runners-update-labels.md)
+ [CodeBuild 호스팅 GitLab 실행기로 지원되는 이미지 계산](sample-gitlab-runners-gitlab-ci.images.md)

# CodeBuild 호스팅 GitLab 실행기 정보
<a name="gitlab-runner-questions"></a>

다음은 CodeBuild 호스팅 GitLab 실행기에 대한 몇 가지 일반적인 질문입니다.

## CodeBuild 호스팅 GitLab 실행기에 지원되는 소스 유형은 무엇입니까?
<a name="gitlab-runner-source"></a>

CodeBuild 호스팅 GitLab 실행기는 `GITLAB` 및 `GITLAB_SELF_MANAGED` 소스 유형에 대해 지원됩니다.

## 레이블에 이미지 및 인스턴스 재정의를 언제 포함해야 합니까?
<a name="gitlab-runner-image-label"></a>

각 GitLab CI/CD 파이프라인 작업에 대해 서로 다른 빌드 환경을 지정하기 위해 레이블에 이미지 및 인스턴스 재정의를 포함할 수 있습니다. 이는 여러 CodeBuild 프로젝트 또는 웹후크를 생성할 필요 없이 수행할 수 있습니다.

## 이 기능에 CloudFormation 를 사용할 수 있습니까?
<a name="gitlab-runner-cfn"></a>

예, 프로젝트 웹후크에서 GitLab 워크플로 작업 이벤트 필터를 지정하는 필터 그룹을 CloudFormation 템플릿에 포함할 수 있습니다.

```
Triggers:
  Webhook: true
  FilterGroups:
    - - Type: EVENT
        Pattern: WORKFLOW_JOB_QUEUED
```

자세한 내용은 [GitLab 웹후크 이벤트 필터링(CloudFormation)](gitlab-webhook-events-cfn.md) 단원을 참조하십시오.

 CloudFormation 템플릿에서 프로젝트 자격 증명을 설정하는 데 도움이 필요한 경우 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [AWS::CodeBuild::SourceCredential](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codebuild-sourcecredential.html)을 참조하세요.

## 이 기능을 사용할 때 암호를 마스킹하려면 어떻게 해야 하나요?
<a name="gitlab-runner-secrets"></a>

기본적으로 로그에 인쇄된 보안 암호는 마스킹되지 않습니다. 보안 암호를 마스킹하려면 CI/CD 환경 변수 설정을 업데이트하면 됩니다.

**GitLab에서 보안 암호를 마스킹하려면**

1. **GitLab 설정**에서 **CI/CD**를 선택합니다.

1. **변수**에서 마스킹하려는 보안 암호에 대해 **편집**을 선택합니다.

1. **가시성**에서 **변수 마스킹**을 선택한 다음 **변수 업데이트**를 선택하여 변경 사항을 저장합니다.

## 단일 그룹 내의 여러 프로젝트에서 GitLab 웹후크 이벤트를 받을 수 있나요?
<a name="gitlab-runner-webhooks"></a>

CodeBuild는 지정된 GitLab 그룹에서 이벤트를 수신하는 그룹 웹후크를 지원합니다. 자세한 내용은 [GitLab 그룹 웹후크](gitlab-group-webhook.md) 단원을 참조하십시오.

## 자체 관리형 실행기의 도커 실행기에서 작업을 실행할 수 있나요? 예를 들어 특정 이미지에서 파이프라인 작업을 실행하여 별도의 격리된 컨테이너에서 동일한 빌드 환경을 유지하고 싶습니다.
<a name="gitlab-runner-custom-image"></a>

[사용자 지정 이미지로 프로젝트를 생성](create-project.md#environment-image.console)하거나 `.gitlab-ci.yml` 파일의 [이미지를 재정의](sample-gitlab-runners.md#sample-gitlab-runners-gitlab-ci)하여 특정 이미지로 CodeBuild에서 GitLab 자체 관리형 실행기를 실행할 수 있습니다.

## CodeBuild의 자체 관리형 실행기는 어떤 실행기로 실행되나요?
<a name="gitlab-runner-shell-executor"></a>

CodeBuild의 자체 관리형 실행기는 쉘 실행기로 실행되며, 여기서 빌드는 도커 컨테이너 내에서 실행 중인 GitLab 실행기와 함께 로컬로 실행됩니다.

## 자체 관리형 실행기와 함께 buildspec 명령을 제공할 수 있나요?
<a name="gitlab-runner-buildspec-commands"></a>

예, 자체 관리형 실행기와 함께 buildspec 명령을 추가할 수 있습니다. GitLab 리포지토리에 buildspec.yml 파일을 제공하고 작업의 **태그** 섹션에서 `buildspec-override:true` 태그를 사용할 수 있습니다. 자세한 내용은 [buildspec 파일 이름 및 스토리지 위치](build-spec-ref.md#build-spec-ref-name-storage) 단원을 참조하십시오.

## CodeBuild 호스팅 GitLab 실행기 사용을 지원하는 리전은 무엇입니까?
<a name="gitlab-runner-hosted-regions"></a>

CodeBuild 호스팅 GitLab 실행기는 모든 CodeBuild 리전에서 지원됩니다. CodeBuild를 사용할 수 AWS 리전 있는 위치에 대한 자세한 내용은 [AWS 리전별 서비스를](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) 참조하세요.

## CodeBuild 호스팅 GitLab 실행기 사용을 지원하는 플랫폼은 무엇입니까?
<a name="gitlab-runner-platform"></a>

CodeBuild 호스팅 GitLab 실행기는 Amazon EC2와 [AWS Lambda](lambda.md) 컴퓨팅 모두에서 지원됩니다. Amazon Linux 2, Amazon Linux 2023, Ubuntu 및 Windows Server Core 2019 플랫폼을 사용할 수 있습니다. 자세한 내용은 [EC2 컴퓨팅 이미지](ec2-compute-images.md) 및 [Lambda 컴퓨팅 이미지](lambda-compute-images.md) 섹션을 참조하세요.

# 자습서: CodeBuild 호스팅 GitLab 실행기 구성
<a name="sample-gitlab-runners"></a>

이 자습서에서는 GitLab CI/CD 파이프라인 작업을 실행하도록 CodeBuild 프로젝트를 구성하는 방법을 보여줍니다. GitLab 또는 GitLab Self Managed with CodeBuild 사용에 대한 자세한 내용은 [의 자체 관리형 GitLab 실행기 AWS CodeBuild](gitlab-runner.md) 섹션을 참조하세요.<a name="sample-gitlab-runners-prerequisites"></a>

이 자습서를 완료하려면 먼저 다음을 수행해야 합니다.
+ CodeConnections를 사용하여 OAuth 앱에 연결합니다. OAuth 앱에 연결할 때는 CodeBuild 콘솔을 사용하여 연결해야 합니다. 자세한 지침은 [CodeBuild의 GitLab 액세스](access-tokens-gitlab-overview.md) 섹션을 참조하세요.
+ CodeBuild를 GitLab 계정에 연결합니다. 콘솔에서 GitLab을 소스 공급자로 추가하여 연결할 수 있습니다. 지침은 [CodeBuild의 GitLab 액세스](access-tokens-gitlab-overview.md) 섹션을 참조하세요.
**참고**  
이는 계정에 대해 GitLab에 연결하지 않은 경우에만 수행하면 됩니다.  
이 기능을 사용하면 CodeBuild에 GitLab OAuth 앱의 `create_runner` 및 `manage_runner`와 같은 추가 권한이 필요합니다. 특정 GitLab 계정에 대한 기존 CodeConnections가 있는 경우 권한 업데이트를 자동으로 요청하지 않습니다. 이렇게 하려면 CodeConnections 콘솔로 이동하여 동일한 GitLab 계정에 더미 연결을 생성하여 재인증을 트리거하여 추가 권한을 가져올 수 있습니다. 이렇게 하면 모든 기존 연결에서 실행기 기능을 사용할 수 있습니다. 완료되면 더미 연결을 삭제할 수 있습니다.

## 1단계: 웹후크를 사용하여 CodeBuild 프로젝트 생성
<a name="sample-gitlab-runners-create-project"></a>

이 단계에서는 웹후크를 사용하여 CodeBuild 프로젝트를 생성하고 GitLab 콘솔에서 검토합니다.

**웹후크를 사용하여 CodeBuild 프로젝트를 생성하려면**

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.

1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.

   **프로젝트 유형**에서 **Runner 프로젝트를** 선택합니다.
   +  **러너**에서: 
     + **Runner 공급자**에서 **GitLab**을 선택합니다.
     +  **자격 증명**에서 다음 중 하나를 선택합니다.
       + **기본 소스 자격 증명**을 선택합니다. 기본 연결은 모든 프로젝트에서 기본 GitLab 연결을 적용합니다.
       + **사용자 지정 소스 자격 증명**을 선택합니다. 사용자 지정 연결은 계정의 기본 설정을 재정의하는 사용자 지정 GitLab 연결을 적용합니다.
**참고**  
공급자에 대한 연결을 아직 생성하지 않은 경우 새 GitLab 연결을 생성해야 합니다. 지침은 [GitLab에 CodeBuild 연결](access-tokens-gitlab-overview.md#connections-gitlab) 섹션을 참조하세요.
     + **러너 위치에서** **리포지토리**를 선택합니다.
     +  **리포지토리 이름**에서 네임스페이스와 함께 프로젝트 경로를 지정하여 GitLab의 프로젝트 이름을 선택합니다.
   +  **환경**에서 다음과 같이 합니다.
     + 지원되는 **환경 이미지**와 **컴퓨팅**을 선택합니다. GitLab CI/CD 파이프라인 YAML의 레이블을 사용하여 이미지 및 인스턴스 설정을 재정의할 수 있습니다. 자세한 내용은 [2단계: 리포지토리에 .gitlab-ci.yml 파일 생성](#sample-gitlab-runners-gitlab-ci) 단원을 참조하십시오.
   +  **Buildspec**에서 다음과 같이 합니다.
     + `buildspec-override:true`가 레이블로 추가되지 않는 한 buildspec은 무시됩니다. 대신 CodeBuild는 자체 관리형 실행기를 설정하는 명령을 사용하도록 재정의합니다.

1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다.

1. `https://gitlab.com/user-name/repository-name/-/hooks`에서 GitLab 콘솔을 열어 웹후크가 생성되었고 **워크플로 작업** 이벤트를 전달할 수 있는지 확인합니다.

## 2단계: 리포지토리에 .gitlab-ci.yml 파일 생성
<a name="sample-gitlab-runners-gitlab-ci"></a>

이 단계에서는 [https://gitlab.com/](https://gitlab.com/)에서 `.gitlab-ci.yml` 파일을 생성하여 빌드 환경을 구성하고 CodeBuild에서 GitLab 자체 관리형 실행기를 사용합니다. 자세한 내용은 [자체 관리형 실행기 사용](https://docs.gitlab.com/runner/#use-self-managed-runners)을 참조하세요.

### GitLab CI/CD 파이프라인 YAML 업데이트
<a name="sample-gitlab-runners-update-yaml.setup"></a>

`https://gitlab.com/user-name/project-name/-/tree/branch-name` 섹션으로 이동하여 리포지토리에서 `.gitlab-ci.yml` 파일을 생성합니다. 다음 중 하나를 수행하여 빌드 환경을 구성할 수 있습니다.
+ CodeBuild 프로젝트 이름을 지정할 수 있습니다. 이 경우 빌드는 컴퓨팅, 이미지, 이미지 버전 및 인스턴스 크기에 대한 기존 프로젝트 구성을 사용합니다. 프로젝트 이름은 GitLab 작업의 AWS관련 설정을 특정 CodeBuild 프로젝트에 연결하는 데 필요합니다. YAML에 프로젝트 이름을 포함하면 CodeBuild가 올바른 프로젝트 설정으로 작업을 호출할 수 있습니다.

  ```
  tags:
      - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
  ```

  `$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME`은 빌드를 특정 파이프라인 작업 실행에 매핑하고 파이프라인 실행이 취소될 때 빌드를 중지하는 데 필요합니다.
**참고**  
*<project-name>*이 CodeBuild에서 생성한 프로젝트의 이름과 일치하는지 확인합니다. 일치하지 않으면 CodeBuild는 웹후크를 처리하지 않고 GitLab CI/CD 파이프라인이 중단될 수 있습니다.

  다음은 GitLab CI/CD 파이프라인 YAML의 예입니다.

  ```
  workflow:
    name: HelloWorld
  stages:          # List of stages for jobs, and their order of execution
    - build
  
  build-job:       # This job runs in the build stage, which runs first.
    stage: build
    script:
      - echo "Hello World!"
    tags:
      - codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
  ```
+ 태그에서 이미지 및 컴퓨팅 유형을 재정의할 수도 있습니다. 큐레이션된 이미지 목록은 섹션을 참조[CodeBuild 호스팅 GitLab 실행기로 지원되는 이미지 계산](sample-gitlab-runners-gitlab-ci.images.md)하세요. 사용자 지정 이미지 사용은 섹션을 참조하세요[CodeBuild 호스팅 GitLab 실행기에서 지원되는 레이블 재정의](gitlab-runners-update-labels.md). 태그의 컴퓨팅 유형과 이미지가 프로젝트의 환경 설정을 재정의합니다. Amazon EC2 컴퓨팅 빌드의 환경 설정을 재정의하려면 다음 구문을 사용합니다.

  ```
  tags:
      - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
      - image:<environment-type>-<image-identifier>
      - instance-size:<instance-size>
  ```

  다음은 GitLab CI/CD 파이프라인 YAML의 예입니다.

  ```
  stages:
    - build
  
  build-job:
    stage: build
    script:
      - echo "Hello World!"
    tags:
      - codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
      - image:arm-3.0
      - instance-size:small
  ```
+ 태그의 빌드에 사용되는 플릿을 재정의할 수 있습니다. 이렇게 하면 지정된 플릿을 사용하도록 프로젝트에 구성된 플릿 설정이 재정의됩니다. 자세한 내용은 [예약 용량 플릿에서 빌드 실행](fleets.md) 단원을 참조하십시오. Amazon EC2 컴퓨팅 빌드의 플릿 설정을 재정의하려면 다음 구문을 사용합니다.

  ```
  tags:
      - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
      - fleet:<fleet-name>
  ```

  빌드에 사용되는 플릿과 이미지를 모두 재정의하려면 다음 구문을 사용합니다.

  ```
  tags:
      - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
      - fleet:<fleet-name>                    
      - image:<environment-type>-<image-identifier>
  ```

  다음은 GitLab CI/CD 파이프라인 YAML의 예입니다.

  ```
  stages:
    - build
  
  build-job:
    stage: build
    script:
      - echo "Hello World!"
    tags:
      - codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
      - fleet:myFleet
      - image:arm-3.0
  ```
+ 사용자 지정 이미지에서 GitLab CI/CD 파이프라인 작업을 실행하려면 CodeBuild 프로젝트에서 사용자 지정 이미지를 구성하고 이미지 재정의 레이블을 제공하지 않아도 됩니다. CodeBuild는 이미지 재정의 레이블이 제공되지 않은 경우 프로젝트에 구성된 이미지를 사용합니다.

`.gitlab-ci.yml`에 변경 사항을 커밋하면 GitLab 파이프라인이 트리거되고 `build-job`이 CodeBuild에서 빌드를 시작하는 웹후크 알림을 보냅니다.

### buildspec 명령 실행 INSTALL, PRE\$1BUILD 및 POST\$1BUILD 단계
<a name="sample-gitlab-runners-update-yaml.buildspec"></a>

기본적으로 CodeBuild는 자체 관리형 GitLab 빌드를 실행할 때 빌드 사양 명령을 무시합니다. 빌드 중에 buildspec 명령을 실행하려면 `buildspec-override:true`를 접미사로 `tags`에 추가할 수 있습니다.

```
tags:
    - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
    - buildspec-override:true
```

이 명령을 사용하면 CodeBuild는 컨테이너의 기본 소스 폴더에 `gitlab-runner`라는 폴더를 생성합니다. `BUILD` 단계 중에 GitLab 실행기가 시작되면 실행기가 `gitlab-runner` 디렉터리에서 실행됩니다.

자체 관리형 GitLab 빌드에서 buildspec 재정의를 사용할 때 몇 가지 제한 사항이 있습니다.
+ CodeBuild는 `BUILD` 단계에서 자체 관리형 실행기가 실행되므로 `BUILD` 단계 중에 buildspec 명령을 실행하지 않습니다.
+ CodeBuild는 `DOWNLOAD_SOURCE` 단계 중에 기본 또는 보조 소스를 다운로드하지 않습니다. buildspec 파일이 구성된 경우 해당 파일만 프로젝트의 기본 소스에서 다운로드됩니다.
+ `PRE_BUILD` 또는 `INSTALL` 단계에서 빌드 명령이 실패하면 CodeBuild는 자체 관리형 실행기를 시작하지 않으며 GitLab CI/CD 파이프라인 작업을 수동으로 취소해야 합니다.
+ CodeBuild는 만료 시간이 1시간인 `DOWNLOAD_SOURCE` 단계 중에 실행기 토큰을 가져옵니다. `PRE_BUILD` 또는 `INSTALL` 단계가 1시간을 초과하면 GitLab 자체 관리형 실행기가 시작되기 전에 실행기 토큰이 만료될 수 있습니다.

## 3단계: 결과 검토
<a name="sample-gitlab-runners-verify"></a>

GitLab CI/CD 파이프라인 실행이 발생할 때마다 CodeBuild는 웹후크를 통해 CI/CD 파이프라인 작업 이벤트를 수신합니다. CI/CD 파이프라인의 각 작업에 대해 CodeBuild는 임시 GitLab 실행기를 실행하기 위한 빌드를 시작합니다. 실행기는 단일 CI/CD 파이프라인 작업을 실행할 책임이 있습니다. 작업이 완료되면 실행기와 관련 빌드 프로세스가 즉시 종료됩니다.

CI/CD 파이프라인 작업 로그를 보려면 GitLab의 리포지토리로 이동하여 **빌드**, **작업**을 선택한 다음 로그를 검토하려는 특정 **작업**을 선택합니다.

CodeBuild에서 자체 관리형 실행기가 작업을 픽업할 때까지 기다리는 동안 로그에서 요청된 레이블을 검토할 수 있습니다.

## GitLab 웹후크 이벤트 필터링(CloudFormation)
<a name="sample-gitlab-runners-webhooks-cfn"></a>

 CloudFormation 템플릿의 다음 YAML 형식 부분은 빌드가 true로 평가될 때 빌드를 트리거하는 필터 그룹을 생성합니다. 다음 필터 그룹은 정규식 `\[CI-CodeBuild\]`와 일치하는 CI/CD 파이프라인 이름이 있는 GitLab CI/CD 파이프라인 작업 요청을 지정합니다.

```
CodeBuildProject:
  Type: AWS::CodeBuild::Project
  Properties:
    Name: MyProject
    ServiceRole: service-role
    Artifacts:
      Type: NO_ARTIFACTS
    Environment:
      Type: LINUX_CONTAINER
      ComputeType: BUILD_GENERAL1_SMALL
      Image: aws/codebuild/standard:5.0
    Source:
      Type: GITLAB
      Location: CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION
    Triggers:
      Webhook: true
      ScopeConfiguration:
        Name: group-name
        Scope: GITLAB_GROUP
      FilterGroups:
        - - Type: EVENT
            Pattern: WORKFLOW_JOB_QUEUED
          - Type: WORKFLOW_NAME
            Pattern: \[CI-CodeBuild\]
```

# CodeBuild 호스팅 GitLab 실행기에서 지원되는 레이블 재정의
<a name="gitlab-runners-update-labels"></a>

GitLab CI/CD 파이프라인 YAML에서 자체 관리형 실행기 빌드를 수정하는 다양한 레이블 재정의를 제공할 수 있습니다. CodeBuild에서 인식하지 못하는 빌드는 무시되지만 웹후크 요청에 실패하지는 않습니다. 예를 들어, 다음 YAML에는 이미지, 인스턴스 크기, 플릿 및 빌드 사양에 대한 재정의가 포함됩니다.

```
workflow:
  name: HelloWorld
stages:
  - build

build-job:
  stage: build
  script:
    - echo "Hello World!"
  tags:
    - codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
    - image:arm-3.0
    - instance-size:small
    - fleet:myFleet
    - buildspec-override:true
```

`codebuild-<project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME`(필수)
+ 예시: `codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME`
+ 모든 GitLab CI/CD 파이프라인 YAMLs에 필요합니다. *<project name>*은 자체 관리형 실행기 웹후크가 구성된 프로젝트의 이름과 같아야 합니다.

`image:<environment-type>-<image-identifier>`
+ 예시: `image:arm-3.0`
+ 자체 관리형 실행기 빌드를 시작할 때 사용되는 이미지 및 환경 유형을 재정의합니다. 지원되는 값에 대한 자세한 내용은 [CodeBuild 호스팅 GitLab 실행기로 지원되는 이미지 계산](sample-gitlab-runners-gitlab-ci.images.md) 섹션을 참조하세요.
  + 사용자 지정 이미지와 함께 사용되는 이미지 및 환경 유형을 재정의하려면 `image:custom-<environment-type>-<custom-image-identifier>`
  + 예시: `image:custom-arm-public.ecr.aws/codebuild/amazonlinux-aarch64-standard:3.0`
**참고**  
사용자 지정 이미지가 프라이빗 레지스트리에 있는 경우 섹션을 참조하세요[자체 호스팅 러너에 대한 프라이빗 레지스트리 자격 증명 구성](private-registry-sample-configure-runners.md).

`instance-size:<instance-size>`
+ 예시: `instance-size:small`
+ 자체 관리형 실행기 빌드를 시작할 때 사용되는 인스턴스 유형을 재정의합니다. 지원되는 값에 대한 자세한 내용은 [CodeBuild 호스팅 GitLab 실행기로 지원되는 이미지 계산](sample-gitlab-runners-gitlab-ci.images.md) 섹션을 참조하세요.

`fleet:<fleet-name>`
+ 예시: `fleet:myFleet`
+ 지정된 플릿을 사용하도록 프로젝트에 구성된 플릿 설정을 재정의합니다. 자세한 내용은 [예약 용량 플릿에서 빌드 실행](fleets.md) 단원을 참조하십시오.

`buildspec-override:<boolean>`
+ 예시: `buildspec-override:true`
+ `true`로 설정된 경우 빌드가 `INSTALL`, `PRE_BUILD` 및 `POST_BUILD` 단계에서 buildspec 명령을 실행하도록 허용합니다.

# CodeBuild 호스팅 GitLab 실행기로 지원되는 이미지 계산
<a name="sample-gitlab-runners-gitlab-ci.images"></a>

[자습서: CodeBuild 호스팅 GitLab 실행기 구성](sample-gitlab-runners.md)에서 구성한 레이블에서 처음 세 열의 값을 사용하여 Amazon EC2 환경 설정을 재정의할 수 있습니다. CodeBuild는 다음과 같은 Amazon EC2 컴퓨팅 이미지를 제공합니다. 해당 내용은 다음을 참조하세요.

<a name="build-env-ref.supported-images"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/sample-gitlab-runners-gitlab-ci.images.html)

또한 다음 값을 사용하여 Lambda 환경 설정을 재정의할 수 있습니다. CodeBuild Lambda 컴퓨팅에 대한 자세한 내용은 [AWS Lambda 컴퓨팅 기반 빌드 실행](lambda.md) 섹션을 참조하세요. CodeBuild는 다음 Lambda 컴퓨팅 이미지를 지원합니다.

<a name="lambda.supported-images"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/sample-gitlab-runners-gitlab-ci.images.html)

자세한 내용은 [빌드 환경 컴퓨팅 모드 및 유형](build-env-ref-compute-types.md) 및 [CodeBuild가 제공하는 도커 이미지](build-env-ref-available.md) 섹션을 참조하세요.

# 의 자체 관리형 Buildkite 실행기 AWS CodeBuild
<a name="buildkite-runner"></a>

CodeBuild 컨테이너에서 자체 호스팅된 Buildkite 러너를 설정하여 Buildkite 작업을 처리하도록 프로젝트를 구성할 수 있습니다. 이는 CodeBuild 프로젝트를 사용하여 웹후크를 설정하고 CodeBuild 시스템에서 호스팅되는 자체 호스팅 러너를 사용하도록 Buildkite 파이프라인 YAML 단계를 업데이트하여 수행할 수 있습니다.

Buildkite 작업을 실행하도록 CodeBuild 프로젝트를 구성하는 상위 단계는 다음과 같습니다.
+ CodeBuild 콘솔로 이동하여 Buildkite 실행기 프로젝트 실행기 유형 구성으로 CodeBuild 프로젝트를 생성합니다.
+ Buildkite 조직에 `job.scheduled` 웹후크를 추가합니다.
+ Buildkite에서 Buildkite 파이프라인 YAML 단계를 업데이트하여 빌드 환경을 구성합니다.

자세한 절차는 [자습서: CodeBuild 호스팅 Buildkite 실행기 구성](sample-runner-buildkite.md) 섹션을 참조하세요. 이 기능을 사용하면 Buildkite 작업이 네이티브 통합을 통해 IAM AWS,, 및 Amazon VPC와 같은 기능을 통해 보안 AWS Secrets Manager AWS CloudTrail및 편의를 제공할 수 있습니다. ARM 기반 인스턴스를 포함하여 최신 인스턴스 유형에 액세스할 수 있습니다.

# CodeBuild 호스팅 Buildkite 실행기 정보
<a name="buildkite-runner-about"></a>

다음은 CodeBuild 호스팅 Buildkite 실행기에 대한 몇 가지 일반적인 질문입니다.

## 레이블에 이미지 및 인스턴스 재정의를 언제 포함해야 합니까?
<a name="buildkite-runner-about-overrides"></a>

레이블에 이미지 및 인스턴스 재정의를 포함하여 각 Buildkite 작업에 대해 서로 다른 빌드 환경을 지정할 수 있습니다. 이는 여러 CodeBuild 프로젝트 또는 웹후크를 생성할 필요 없이 수행할 수 있습니다. 예를 들어, 이는 [Buildkite 작업에 매트릭스](https://buildkite.com/docs/pipelines/configure/workflows/build-matrix)를 사용해야 할 때 유용합니다.

```
agents:
  queue: "myQueue"
steps:
  - command: "echo \"Hello World\""
    agents:
      project: "codebuild-myProject"
      image: "{{matrix.os}}"
      instance-size: "{{matrix.size}}"
    matrix:
      setup:
        os:
          - "arm-3.0"
          - "al2-5.0"
        size:
          - "small"
          - "large"
```

## CodeBuild가 Buildkite 내에서 웹후크를 자동으로 생성할 수 있나요?
<a name="buildkite-runner-about-auto-create"></a>

현재 Buildkite에서는 콘솔을 사용하여 모든 웹후크를 수동으로 생성해야 합니다. 의 자습서에 따라 Buildkite 콘솔에서 수동으로 Buildkite 웹후크를 [자습서: CodeBuild 호스팅 Buildkite 실행기 구성](sample-runner-buildkite.md) 생성할 수 있습니다.

## CloudFormation 를 사용하여 Buildkite 웹후크를 생성할 수 있습니까?
<a name="buildkite-runner-about-cloudformation"></a>

CloudFormation Buildkite는 콘솔을 사용하여 수동으로 웹후크를 생성해야 하므로는 현재 Buildkite 러너 웹후크에 대해 지원되지 않습니다.

## CodeBuild 호스팅 Buildkite 실행기 사용을 지원하는 리전은 어디입니까?
<a name="buildkite-runner-about-regions"></a>

CodeBuild 호스팅 Buildkite 실행기는 모든 CodeBuild 리전에서 지원됩니다. CodeBuild를 사용할 수 있는 AWS 리전에 대한 자세한 내용은 [AWS 리전별 서비스를](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) 참조하세요.

# 자습서: CodeBuild 호스팅 Buildkite 실행기 구성
<a name="sample-runner-buildkite"></a>

이 자습서에서는 Buildkite 작업을 실행하도록 CodeBuild 프로젝트를 구성하는 방법을 보여줍니다. CodeBuild에서 Buildkite를 사용하는 방법에 대한 자세한 내용은 섹션을 참조하세요[의 자체 관리형 Buildkite 실행기 AWS CodeBuild](buildkite-runner.md).<a name="sample-runner-buildkite-prerequisites"></a>

이 자습서를 완료하려면 먼저 다음을 수행해야 합니다.
+ Buildkite 조직에 액세스할 수 있습니다. Buildkite 계정 및 조직 설정에 대한 자세한 내용은이 [ 시작하기 자습서를](https://buildkite.com/docs/pipelines/getting-started) 참조하세요.
+ 자체 호스팅 러너를 사용하도록 구성된 Buildkite 파이프라인, 클러스터 및 대기열을 생성합니다. 이러한 리소스 설정에 대한 자세한 내용은 [ Buildkite 파이프라인 설정 자습서를](https://buildkite.com/docs/pipelines/create-your-own) 참조하세요.  
![\[Buildkite에서 프로젝트 빌드\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/buildkite-first.png)

## 1단계: Buildkite 에이전트 토큰 생성
<a name="w2aac26c33c12c13b7"></a>

이 단계에서는 CodeBuild 자체 호스팅 실행기를 인증하는 데 사용할 에이전트 토큰을 Buildkite 내에서 생성합니다. 이 리소스에 대한 자세한 내용은 [Buildkite 에이전트 토큰을 참조하세요](https://buildkite.com/docs/agent/v3/tokens).

**Buildkite 에이전트 토큰을 생성하려면**

1. Buildkite 클러스터에서 **에이전트 토큰**을 선택한 다음 **새 토큰**을 선택합니다.

1. 토큰에 설명을 추가하고 **토큰 생성을** 클릭합니다.

1. 에이전트 토큰 값은 나중에 CodeBuild 프로젝트 설정 중에 사용되므로 저장합니다.  
![\[Buildkite의 에이전트 토큰\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/buildkite-createtoken.png)

## 2단계: Webhook를 사용하여 CodeBuild 프로젝트 생성
<a name="sample-runner-buildkite-create-project"></a>

**웹후크를 사용하여 CodeBuild 프로젝트를 생성하려면**

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.

1. 자체 호스팅 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
   +  **프로젝트 구성**에서 **Runner 프로젝트를** 선택합니다. **러너**에서: 
     +  **러너 공급자**에서 **Buildkite**를 선택합니다.
     + **Buildkite 에이전트 토큰**에서 **보안 암호 생성 페이지를 사용하여 새 에이전트 토큰 생성**을 선택합니다. 위에서 생성한 Buildkite 에이전트 토큰 AWS Secrets Manager 과 동일한 보안 암호 값을 사용하여에서 새 보안 암호를 생성하라는 메시지가 표시됩니다.
     + (선택 사항) 작업에 CodeBuild 관리형 자격 증명을 사용하려면 **Buildkite 소스 자격 증명 옵션**에서 작업의 소스 리포지토리 공급자를 선택하고 자격 증명이 계정에 대해 구성되어 있는지 확인합니다. 또한, Buildkite 파이프라인이 **HTTPS를 사용한 체크아웃**을 사용하는지 확인합니다.
**참고**  
Buildkite는 작업의 소스를 가져오기 위해 빌드 환경 내에 소스 자격 증명이 필요합니다. 사용 가능한 소스 자격 증명 옵션은 섹션을 참조[프라이빗 리포지토리에 대한 Buildkite 인증](#sample-runner-buildkite-config)하세요.
   + (선택 사항) **환경에서**: 
     + 지원되는 **환경 이미지**와 **컴퓨팅**을 선택합니다.

       Buildkite YAML 단계에서 레이블을 사용하여 이미지 및 인스턴스 설정을 재정의할 수 있습니다. 자세한 내용은 [4단계: Buildkite 파이프라인 단계 업데이트](#sample-runner-buildkite-update-pipeline) 단원을 참조하십시오.
   + (선택 사항) **Buildspec**에서: 
     + 가 레이블로 추가되지 않는 한 buildspec`buildspec-override: "true"`은 기본적으로 무시됩니다. 대신 CodeBuild는 자체 호스팅 러너를 설정하는 명령을 사용하도록 이를 재정의합니다.
**참고**  
CodeBuild는 Buildkite 자체 호스팅 러너 빌드에 대한 buildspec 파일을 지원하지 않습니다. 인라인 buildspecs의 경우 CodeBuild 관리형 소스 자격 증명을 구성한 경우 buildspec에서 [ git-credential-helper](https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html#build-spec.env.git-credential-helper)를 활성화해야 합니다.

1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다.

1. **웹후크 생성** 팝업에서 **페이로드 URL** 및 **보안 암호** 값을 저장합니다. 팝업의 지침에 따라 새 Buildkite 조직 웹후크를 생성하거나 다음 섹션으로 계속 진행합니다.

## 3단계: Buildkite 내에서 CodeBuild 웹후크 생성
<a name="sample-runner-buildkite-codebuild-webhook"></a>

이 단계에서는 CodeBuild 웹후크의 **페이로드 URL** 및 **보안** 암호 값을 사용하여 Buildkite 내에 새 웹후크를 생성합니다. 이 웹후크는 유효한 Buildkite 작업이 시작될 때 CodeBuild 내에서 빌드를 트리거하는 데 사용됩니다.

**Buildkite에서 새 웹후크를 생성하려면**

1. Buildkite 조직의 **설정** 페이지로 이동합니다.

1. **통합**에서 **알림 서비스를** 선택합니다.

1. **Webhook** 상자 옆에 있는 **추가**를 선택합니다. **Webhook 알림 추가** 페이지에서 다음 구성을 사용합니다.

   1. **Webhook URL**에서 저장된 **페이로드 URL** 값을 추가합니다.

   1. **토큰**에서 **토큰을 X-Buildkite-Token으로 전송**이 선택되어 있는지 확인합니다. **토큰** 필드에 웹후크 **보안** 암호 값을 추가합니다.

   1. 에서 **토큰을 X-Buildkite-Token으로 전송**이 선택되어 있는지 확인합니다. **토큰** 필드에 웹후크 **보안** 암호 값을 추가합니다.

   1. **이벤트**에서 `job.scheduled` 웹후크 이벤트를 선택합니다.

   1. (선택 사항) **파이프라인**에서 선택적으로 특정 파이프라인에 대한 빌드만 트리거하도록 선택할 수 있습니다.

1. **Webhook 알림 추가**를 선택합니다.

## 4단계: Buildkite 파이프라인 단계 업데이트
<a name="sample-runner-buildkite-update-pipeline"></a>

이 단계에서는 필요한 레이블과 선택적 재정의를 추가하기 위해 Buildkite 파이프라인의 단계를 업데이트합니다. 지원되는 레이블 재정의의 전체 목록은 섹션을 참조하세요[CodeBuild 호스팅 Buildkite 실행기에서 지원되는 레이블 재정의](buildkite-runner-update-labels.md).

**파이프라인 단계 업데이트**

1. Buildkite 파이프라인을 선택하고 **설정을** 선택한 다음 단계를 선택하여 Buildkite 파이프라인 **단계** 페이지로 이동합니다.

   아직 선택하지 않았다면 **YAML 단계로 변환을** 선택합니다.  
![\[YAML을 업데이트하는 단계입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/buildkite-steps.png)

1. 최소한 CodeBuild 파이프라인의 이름을 참조하는 [ Buildkite 에이전트 태그를 ](https://buildkite.com/docs/agent/v3/cli-start#agent-targeting) 지정해야 합니다. 프로젝트 이름은 Buildkite 작업의 AWS관련 설정을 특정 CodeBuild 프로젝트에 연결하는 데 필요합니다. YAML에 프로젝트 이름을 포함하면 CodeBuild가 올바른 프로젝트 설정으로 작업을 호출할 수 있습니다.

   ```
   agents:
     project: "codebuild-<project name>"
   ```

   다음은 프로젝트 레이블 태그만 있는 Buildkite 파이프라인 단계의 예입니다.

   ```
   agents:
     project: "codebuild-myProject"
   steps:
     - command: "echo \"Hello World\""
   ```

   레이블에서 이미지 및 컴퓨팅 유형을 재정의할 수도 있습니다. 사용 가능한 이미지 목록은 [CodeBuild 호스팅 Buildkite 러너에서 지원되는 컴퓨팅 이미지](buildkite-runner-update-yaml.images.md) 섹션을 참조하세요. 레이블의 컴퓨팅 유형 및 이미지가 프로젝트의 환경 설정을 재정의합니다. CodeBuild EC2 또는 Lambda 컴퓨팅 빌드의 환경 설정을 재정의하려면 다음 구문을 사용합니다.

   ```
   agents:
     project: "codebuild-<project name>"
     image: "<environment-type>-<image-identifier>"
     instance-size: "<instance-size>"
   ```

   다음은 이미지 및 인스턴스 크기 재정의가 있는 Buildkite 파이프라인 단계의 예입니다.

   ```
   agents:
     project: "codebuild-myProject"
     image: "arm-3.0"
     instance-size: "small"
   steps:
     - command: "echo \"Hello World\""
   ```

   레이블에서 빌드에 사용되는 플릿을 재정의할 수 있습니다. 이렇게 하면 지정된 플릿을 사용하도록 프로젝트에 구성된 플릿 설정이 재정의됩니다. 자세한 내용은 [ 예약된 용량 플릿에서 빌드 실행을 참조하세요](https://docs.aws.amazon.com/codebuild/latest/userguide/fleets.html).

   Amazon EC2 컴퓨팅 빌드의 플릿 설정을 재정의하려면 다음 구문을 사용합니다.

   ```
   agents:
     project: "codebuild-<project name>"
     fleet: "<fleet-name>"
   ```

   빌드에 사용되는 플릿과 이미지를 모두 재정의하려면 다음 구문을 사용합니다.

   ```
   agents:
     project: "codebuild-<project name>"
     fleet: "<fleet-name>"
     image: "<environment-type>-<image-identifier>"
   ```

   다음은 플릿 및 이미지 재정의가 있는 Buildkite 파이프라인 단계의 예입니다.

   ```
   agents:
     project: "codebuild-myProject"
     fleet: "myFleet"
     image: "arm-3.0"
   steps:
     - command: "echo \"Hello World\""
   ```

1. 자체 호스팅 Buildkite 실행기 빌드 중에 인라인 buildspec 명령을 실행하도록 선택할 수 있습니다([INSTALL, PRE\$1BUILD 및 POST\$1BUILD 단계에 대해 buildspec 명령 실행](sample-runner-buildkite-buildspec.md)자세한 내용은 참조). Buildkite 자체 호스팅 러너 빌드 중에 CodeBuild 빌드가 buildspec 명령을 실행하도록 지정하려면 다음 구문을 사용합니다.

   ```
   agents:
     project: "codebuild-<project name>"
     buildspec-override: "true"
   ```

   다음은 buildspec 재정의가 있는 Buildkite 파이프라인의 예입니다.

   ```
   agents:
     project: "codebuild-myProject"
     buildspec-override: "true"
   steps:
     - command: "echo \"Hello World\""
   ```

1. 선택적으로 CodeBuild가 지원하는 레이블 이외의 레이블을 제공할 수 있습니다. 이러한 레이블은 빌드의 속성을 재정의할 목적으로 무시되지만 웹후크 요청에 실패하지는 않습니다. 예를 들어 레이블로 `myLabel: “testLabel"`을 추가해도 레이블은 빌드 실행을 방해하지 않습니다.

## 5단계: 결과 검토
<a name="sample-runner-buildkite-verify"></a>

파이프라인에서 Buildkite 작업이 시작될 때마다 CodeBuild는 Buildkite `job.scheduled` 웹후크를 통해 웹후크 이벤트를 수신합니다. Buildkite 빌드의 각 작업에 대해 CodeBuild는 임시 Buildkite 실행기를 실행하기 위한 빌드를 시작합니다. 실행기는 단일 Buildkite 작업을 실행할 책임이 있습니다. 작업이 완료되면 실행기와 관련 빌드 프로세스가 즉시 종료됩니다.

워크플로 작업 로그를 보려면 Buildkite 파이프라인으로 이동하여 최신 빌드를 선택합니다(새 빌드를 선택하여 **새 빌드**를 트리거할 수 있음). 각 작업에 연결된 CodeBuild 빌드가 시작되고 작업을 픽업하면 Buildkite 콘솔 내에 작업에 대한 로그가 표시되어야 합니다.

![\[결과를 검토합니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/buildkite-log.png)


## 프라이빗 리포지토리에 대한 Buildkite 인증
<a name="sample-runner-buildkite-config"></a>

Buildkite 파이프라인 내에 프라이빗 리포지토리가 구성된 경우 Buildkite는 프라이빗 리포지토리에서 가져오기 위해 자체 호스팅된 러너에 자격 증명을 벤딩하지 않으므로 빌드 [환경 내에서 리포지토리를 가져오려면 추가 권한이](https://buildkite.com/docs/agent/v3/github-ssh-keys) 필요합니다. Buildkite 자체 호스팅 러너 에이전트를 외부 프라이빗 소스 리포지토리에 인증하려면 다음 옵션 중 하나를 사용할 수 있습니다.

**CodeBuild로 인증하려면**

CodeBuild는 지원되는 소스 유형에 대한 관리형 자격 증명 처리를 제공합니다. CodeBuild 소스 자격 증명을 사용하여 작업의 소스 리포지토리를 가져오려면 다음 단계를 사용할 수 있습니다.

1. CodeBuild 콘솔에서의 단계를 사용하여 **프로젝트 편집**으로 이동하거나 새 CodeBuild 프로젝트를 생성합니다[2단계: Webhook를 사용하여 CodeBuild 프로젝트 생성](#sample-runner-buildkite-create-project).

1. **Buildkite 소스 자격 증명 옵션**에서 작업의 소스 리포지토리 공급자를 선택합니다.

   1. 계정 수준 CodeBuild 자격 증명을 사용하려면 자격 증명이 올바르게 구성되었는지 확인합니다. 또한 프로젝트에 인라인 buildspec이 구성된 경우 [ git-credential-helper](https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html#build-spec.env.git-credential-helper)가 활성화되어 있는지 확인합니다.

   1. 프로젝트 수준 CodeBuild 자격 증명을 사용하려면 **이 프로젝트에 대해서만 자격 증명 재정의 사용을 선택하고 프로젝트에** 대한 자격 증명을 설정합니다.

1. Buildkite 파이프라인 설정에서 **리포지토리 설정**으로 이동합니다. **HTTPS를 사용하여 소스 리포지토리 체크아웃 설정을 체크아웃**으로 설정  
![\[결과를 검토합니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/buildkite-repo-https.png)

**Buildkite 보안 암호로 인증하려면**

Buildkite는 [ ssh 키를 사용하여 외부 소스 리포지토리에 자체 호스팅된 러너를 인증하는 데 사용할 수 있는 ssh-checkout 플러그인](https://github.com/buildkite-plugins/git-ssh-checkout-buildkite-plugin)을 유지 관리합니다. 키 값은 [Buildkite 보안 암호](https://buildkite.com/docs/pipelines/security/secrets/buildkite-secrets)로 저장되며 프라이빗 리포지토리를 가져오려고 할 때 Buildkite 자체 호스팅 러너 에이전트가 자동으로 가져옵니다. Buildkite 파이프라인에 대한 ssh-checkout 플러그인을 구성하려면 다음 단계를 사용할 수 있습니다.

1. 이메일 주소를 사용하여 프라이빗 및 퍼블릭 ssh 키를 생성합니다. 예: `ssh-keygen -t rsa -b 4096 -C "myEmail@address.com"`

1. 프라이빗 소스 리포지토리에 퍼블릭 키를 추가합니다. 예를 들어 [이 가이드](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)에 따라 GitHub 계정에 키를 추가할 수 있습니다.

1. Buildkite 클러스터에 [ 새 SSH 키 보안 ](https://buildkite.com/docs/pipelines/hosted-agents/code-access#private-repositories-with-other-providers-add-the-ssh-key-secret) 암호를 추가합니다. Buildkite 클러스터 내에서 **보안** 암호 → **새 보안 암호를** 선택합니다. **키** 필드에 보안 암호의 이름을 추가하고 **값** 필드에 프라이빗 SSH 키를 추가합니다.  
![\[결과를 검토합니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/buildkite-secret.png)

1. Buildkite 파이프라인 내에서 리포지토리 설정으로 이동하여 **SSH**를 사용하도록 체크아웃을 설정합니다.  
![\[결과를 검토합니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/buildkite-repo.png)

1. `git-ssh-checkout` 플러그인을 사용하도록 파이프라인 YAML 단계를 업데이트합니다. 예를 들어 다음 파이프라인 YAML 파일은 위의 Buildkite 보안 키와 함께 체크아웃 작업을 사용합니다.

   ```
   agents:
     project: "codebuild-myProject"
   steps:
     - command: "npm run build"
       plugins:
         - git-ssh-checkout#v0.4.1:
             ssh-secret-key-name: 'SOURCE_SSH_KEY'
   ```

1. CodeBuild 내에서 Buildkite 자체 호스팅 러너 작업을 실행할 때 이제 Buildkite는 프라이빗 리포지토리를 가져올 때 구성된 보안 암호 값을 자동으로 사용합니다.

## 러너 구성 옵션
<a name="sample-buildkite-runner-auth"></a>

프로젝트 구성에서 다음 환경 변수를 지정하여 자체 호스팅 러너의 설정 구성을 수정할 수 있습니다.
+ `CODEBUILD_CONFIG_BUILDKITE_AGENT_TOKEN`: CodeBuild는 Buildkite 자체 호스팅 러너 에이전트를 등록하기 위해에서 AWS Secrets Manager 이 환경 변수의 값으로 구성된 보안 암호 값을 가져옵니다. 이 환경 변수는 유형이어야 하며 `SECRETS_MANAGER`값은 Secrets Manager의 보안 암호 이름이어야 합니다. 모든 Buildkite 실행기 프로젝트에는 Buildkite 에이전트 토큰 환경 변수가 필요합니다.
+ `CODEBUILD_CONFIG_BUILDKITE_CREDENTIAL_DISABLE`: 기본적으로 CodeBuild는 계정 또는 프로젝트 수준 소스 자격 증명을 빌드 환경에 로드합니다. Buildkite 에이전트가 이러한 자격 증명을 사용하여 작업의 소스 리포지토리를 가져오기 때문입니다. 이 동작을 비활성화하려면 값이 로 설정된 상태에서이 환경 변수를 프로젝트에 추가하면 소스 자격 증명`true`이 빌드 환경에 로드되지 않습니다.

# INSTALL, PRE\$1BUILD 및 POST\$1BUILD 단계에 대해 buildspec 명령 실행
<a name="sample-runner-buildkite-buildspec"></a>

기본적으로 CodeBuild는 자체 호스팅 Buildkite 러너 빌드를 실행할 때 모든 buildspec 명령을 무시합니다. 빌드 중에 buildspec 명령을 실행하려면 

```
buildspec-override: "true"
```

 는 레이블에 접미사로 추가할 수 있습니다.

```
agents:
  project: "codebuild-<project name>"
  buildspec-override: "true"
```

이 명령을 사용하면 CodeBuild는 컨테이너의 기본 소스 폴더에 `buildkite-runner`라는 폴더를 생성합니다. `BUILD` 단계 중에 Buildkite 실행기가 시작되면 실행기가 `buildkite-runner` 디렉터리에서 실행됩니다.

자체 호스팅 Buildkite 빌드에서 buildspec 재정의를 사용할 때 몇 가지 제한 사항이 있습니다.
+ Buildkite 에이전트는 작업의 소스 리포지토리를 가져오려면 빌드 환경 내에 소스 자격 증명이 있어야 합니다. 인증에 CodeBuild 소스 자격 증명을 사용하는 경우 buildspec`git-credential-helper`에서를 활성화해야 합니다. 예를 들어 다음 buildspec을 사용하여 Buildkite 빌드에 `git-credential-helper` 대해를 활성화할 수 있습니다.

  ```
  version: 0.2
  env:
    git-credential-helper: yes
  phases:
    pre_build:
      commands:
         - echo "Hello World"
  ```
+ CodeBuild는 `BUILD` 단계에서 자체 호스팅된 실행기가 실행되므로 `BUILD` 단계 중에 buildspec 명령을 실행하지 않습니다.
+ CodeBuild는 Buildkite 러너 빌드에 대한 buildspec 파일을 지원하지 않습니다. Buildlkite 자체 호스팅 러너에는 인라인 buildspecs만 지원됩니다.
+ `PRE_BUILD` 또는 `INSTALL` 단계에서 빌드 명령이 실패하면 CodeBuild는 자체 호스팅된 실행기를 시작하지 않으므로 Buildkite 작업을 수동으로 취소해야 합니다.

# 프로그래밍 방식으로 Buildkite 실행기 설정
<a name="sample-runner-buildkite-CLI"></a>

Buildkite 러너 프로젝트를 프로그래밍 방식으로 구성하려면 다음 리소스를 구성해야 합니다.

**프로그래밍 방식으로 Buildkite 실행기를 생성하려면**

1. Buildkite 에이전트 토큰을 생성하고 토큰을 내에 일반 텍스트로 저장합니다 AWS Secrets Manager.

1. 원하는 구성으로 CodeBuild 프로젝트를 설정합니다. 다음과 같은 추가 속성을 구성해야 합니다.

   1. 이름이 `CODEBUILD_CONFIG_BUILDKITE_AGENT_TOKEN`이고, 유형이 이고`SECRETS_MANAGER`, 값이 Buildkite 클러스터와 연결된 Buildkite 에이전트 토큰과 동일한 환경 값입니다.

   1. 소스 유형이과 같음 `NO_SOURCE`

   1. 프로젝트 서비스 역할의 1단계에서 생성된 보안 암호에 액세스할 수 있는 권한

   예를 들어 다음 명령을 사용하여 CLI를 통해 유효한 Buildkite 러너 프로젝트를 생성할 수 있습니다.

   ```
   aws codebuild create-project \
   --name buildkite-runner-project \
   --source "{\"type\": \"NO_SOURCE\",\"buildspec\":\"\"}" \
   --environment "{\"image\":\"aws/codebuild/amazonlinux-x86_64-standard:5.0\",\"type\":\"LINUX_CONTAINER\",\"computeType\":\"BUILD_GENERAL1_MEDIUM\",\"environmentVariables\":[{\"name\":\"CODEBUILD_CONFIG_BUILDKITE_AGENT_TOKEN\",\"type\":\"SECRETS_MANAGER\",\"value\":\"<buildkite-secret-name>\"}]}" \
   --artifacts "{\"type\": \"NO_ARTIFACTS\"}" \
   --service-role <service-role>
   ```

1. 2단계에서 생성한 프로젝트에 Buildkite 실행기 웹후크를 생성합니다. 웹후크를 생성할 때 다음 구성 옵션을 사용해야 합니다.

   1. **build-type**은와 같아야 합니다. `RUNNER_BUILDKITE_BUILD` 

   1. 유형이 `EVENT` 이고 패턴이 인 필터 `WORKFLOW_JOB_QUEUED` 

   예를 들어 다음 명령을 사용하여 CLI를 통해 유효한 Buildkite 러너 웹후크를 생성할 수 있습니다.

   ```
   aws codebuild create-webhook \
   --project-name buildkite-runner-project \
   --filter-groups "[[{\"type\":\"EVENT\",\"pattern\":\"WORKFLOW_JOB_QUEUED\"}]]" \
   --build-type RUNNER_BUILDKITE_BUILD
   ```

1. `create-webhook` 호출에서 반환한 **페이로드 URL** 및 **보안** 암호 값을 저장하고 자격 증명을 사용하여 Buildkite 콘솔 내에서 웹후크를 생성합니다. 이 리소스를 설정하는 방법에 [자습서: CodeBuild 호스팅 Buildkite 실행기 구성](sample-runner-buildkite.md) 대한 지침은의 Buildkite 내에서 3단계: CodeBuild 웹후크 생성을 참조할 수 있습니다.

# 실패한 빌드 또는 중단 작업에 대한 웹후크 문제 해결
<a name="buildkite-runner-troubleshoot-webhook"></a>

 **문제: ** 

에서 설정한 웹후크[자습서: CodeBuild 호스팅 Buildkite 실행기 구성](sample-runner-buildkite.md)가 작동하지 않거나 워크플로 작업이 Buildkite에서 중단되고 있습니다.

 **가능한 원인: ** 
+ webhook **job.scheduled** 이벤트가 빌드를 트리거하지 못할 수 있습니다. **응답** 로그를 검토하여 응답 또는 오류 메시지를 확인합니다.
+ 작업을 처리하기 위해 Buildkite 자체 호스팅 러너 에이전트를 시작하기 전에 CodeBuild 빌드가 실패합니다.

 **권장 솔루션: ** 

실패한 Buildkite 웹후크 이벤트를 디버깅하려면

1. Buildkite 조직 설정에서 **알림 서비스로** 이동하여 CodeBuild 웹후크를 선택한 다음 **요청 로그**를 찾습니다.

1. 멈춘 Buildkite 작업과 연결된 `job.scheduled` 웹후크 이벤트를 찾습니다. Webhook 페이로드 내의 작업 ID 필드를 사용하여 Webhook 이벤트를 Buildkite 작업과 연관시킬 수 있습니다.

1. **응답** 탭을 선택하고 응답 본문을 확인합니다. **응답** 상태 코드가 `200` 이고 **응답** 본문에 예상치 못한 메시지가 포함되어 있지 않은지 확인합니다.  
![\[웹후크에 대한 응답입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/buildkite-request.png)

# Webhook 권한 문제 해결
<a name="buildkite-runner-troubleshoot-webhook-permissions"></a>

 **문제: ** 

권한 문제로 인해 Buildkite 작업이 작업의 소스 리포지토리를 체크아웃하지 못합니다.

 **가능한 원인: ** 
+ CodeBuild에는 작업의 소스 리포지토리를 체크아웃할 수 있는 충분한 권한이 없습니다.
+ 파이프라인의 리포지토리 설정은 CodeBuild 관리형 자격 증명에 대한 SSH를 사용하여 체크아웃하도록 설정됩니다.

 **권장 솔루션: ** 
+ CodeBuild에 작업의 소스 리포지토리를 체크아웃하도록 구성된 충분한 권한이 있는지 확인합니다. 또한 CodeBuild 프로젝트의 서비스 역할에 구성된 소스 권한 옵션에 액세스할 수 있는 충분한 권한이 있는지 확인합니다.
+ CodeBuild 관리형 소스 리포지토리 자격 증명을 사용하는 경우 HTTPS를 사용한 체크아웃을 사용하도록 Buildkite 파이프라인이 구성되어 있는지 확인합니다.

# CodeBuild 호스팅 Buildkite 실행기에서 지원되는 레이블 재정의
<a name="buildkite-runner-update-labels"></a>

Buildkite 파이프라인 단계에서 에이전트 태그 레이블을 지정하면 자체 호스팅된 러너 빌드를 수정하는 다양한 레이블 재정의를 제공할 수 있습니다. CodeBuild에서 인식하지 못하는 빌드는 무시되지만 웹후크 요청에 실패하지는 않습니다. 예를 들어 다음 워크플로 YAML에는 이미지, 인스턴스 크기, 플릿 및 buildspec에 대한 재정의를 포함합니다.

```
agents:
  queue: "myQueue"
steps:
  - command: "echo \"Hello World\""
    agents:
      project: "codebuild-myProject"
      image: "{{matrix.os}}"
      instance-size: "{{matrix.size}}"
      buildspec-override: "true"
    matrix:
      setup:
        os:
          - "arm-3.0"
          - "al2-5.0"
        size:
          - "small"
          - "large"
```

 `project:codebuild-<project-name>`(필수)
+ 예시: `project: "codebuild-myProject"`
+ 모든 Buildkite 파이프라인 단계 구성에 필요합니다. *<project name>*은 자체 호스팅 러너 웹후크가 구성된 프로젝트의 이름과 같아야 합니다.

`queue: "<queue-name>"`
+ 예시: `queue: "<queue-name>"`
+ Buildkite 작업을 특정 대기열로 라우팅하는 데 사용됩니다. 자세한 내용은 [ Buildkite 에이전트 대기열 태그를 ](https://buildkite.com/docs/agent/v3/cli-start#the-queue-tag) 참조하세요.

 `image: "<environment-type>-<image-identifier>"` 
+ 예시: `image: "arm-3.0"`
+ 큐레이션된 이미지로 자체 호스팅 러너 빌드를 시작할 때 사용되는 이미지 및 환경 유형을 재정의합니다. 지원되는 값에 대한 자세한 내용은 [CodeBuild 호스팅 Buildkite 러너에서 지원되는 컴퓨팅 이미지](buildkite-runner-update-yaml.images.md) 섹션을 참조하세요.

  1. 사용자 지정 이미지와 함께 사용되는 이미지 및 환경 유형을 재정의하려면를 사용합니다. `image: "custom-<environment-type>-<custom-image-identifier>"` 

  1. 예제: 

     ```
     image:
           "custom-arm-public.ecr.aws/codebuild/amazonlinux-aarch64-standard:3.0"
     ```
**참고**  
사용자 지정 이미지가 프라이빗 레지스트리에 있는 경우 CodeBuild 프로젝트에서 적절한 레지스트리 자격 증명을 구성해야 합니다.

`instance-size: "<instance-size>"`
+ 예시: `instance-size: "medium"`
+ 자체 호스팅 실행기 빌드를 시작할 때 사용되는 인스턴스 유형을 재정의합니다. 지원되는 값에 대한 자세한 내용은 [CodeBuild 호스팅 Buildkite 러너에서 지원되는 컴퓨팅 이미지](buildkite-runner-update-yaml.images.md) 섹션을 참조하세요.

`fleet: "<fleet-name>"`
+ 예시: `fleet: "myFleet"`
+ 지정된 플릿을 사용하도록 프로젝트에 구성된 플릿 설정을 재정의합니다. 자세한 내용은 [ 예약된 용량 플릿에서 빌드 실행을 참조하세요](https://docs.aws.amazon.com/codebuild/latest/userguide/fleets.html).

`buildspec-override: "<boolean>"`
+ 예시: `buildspec-override: "true"`
+ `true`로 설정된 경우 빌드가 `INSTALL`, `PRE_BUILD` 및 `POST_BUILD` 단계에서 buildspec 명령을 실행하도록 허용합니다.

# CodeBuild 호스팅 Buildkite 러너에서 지원되는 컴퓨팅 이미지
<a name="buildkite-runner-update-yaml.images"></a>

[의 자체 관리형 Buildkite 실행기 AWS CodeBuild](buildkite-runner.md)에서 구성한 레이블에서 처음 세 열의 값을 사용하여 Amazon EC2 환경 설정을 재정의할 수 있습니다. CodeBuild는 다음과 같은 Amazon EC2 컴퓨팅 이미지를 제공합니다. 해당 내용은 다음을 참조하세요.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/buildkite-runner-update-yaml.images.html)

또한 다음 값을 사용하여 Lambda 환경 설정을 재정의할 수 있습니다. CodeBuild Lambda 컴퓨팅에 대한 자세한 내용은 [AWS Lambda 컴퓨팅 기반 빌드 실행](lambda.md) 섹션을 참조하세요. CodeBuild는 다음 Lambda 컴퓨팅 이미지를 지원합니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/buildkite-runner-update-yaml.images.html)

자세한 내용은 [빌드 환경 컴퓨팅 모드 및 유형](build-env-ref-compute-types.md) 및 [CodeBuild가 제공하는 도커 이미지](build-env-ref-available.md) 섹션을 참조하세요.

# 에서 웹후크 사용 AWS CodeBuild
<a name="webhooks"></a>

AWS CodeBuild 는 GitHub, GitHub Enterprise Server, GitLab, GitLab 자체 관리형 및 Bitbucket과의 웹후크 통합을 지원합니다.

**Topics**
+ [에서 웹후크를 사용하는 모범 사례 AWS CodeBuild](#webhook-best-practices)
+ [Bitbucket Webhook 이벤트](bitbucket-webhook.md)
+ [GitHub 글로벌 및 조직 웹후크](github-global-organization-webhook.md)
+ [GitHub 수동 웹후크](github-manual-webhook.md)
+ [GitHub Webhook 이벤트](github-webhook.md)
+ [GitLab 그룹 웹후크](gitlab-group-webhook.md)
+ [GitLab 수동 웹후크](gitlab-manual-webhook.md)
+ [GitLab 웹후크 이벤트](gitlab-webhook.md)
+ [Buildkite 수동 웹후크](buildkite-manual-webhook.md)
+ [풀 요청 설명 승인](pull-request-build-policy.md)

## 에서 웹후크를 사용하는 모범 사례 AWS CodeBuild
<a name="webhook-best-practices"></a>

퍼블릭 리포지토리를 사용하여 webhook를 설정하는 프로젝트의 경우 다음 옵션을 권장합니다.

`ACTOR_ACCOUNT_ID` 필터 설정  
프로젝트의 webhook 필터 그룹에 `ACTOR_ACCOUNT_ID` 필터를 추가하여 빌드를 트리거할 수 있는 사용자를 지정합니다. CodeBuild로 전달되는 모든 webhook 이벤트는 행위자의 식별자를 지정하는 발신자 정보와 함께 제공됩니다. CodeBuild는 필터에 제공된 정규 표현식 패턴을 기준으로 webhook를 필터링합니다. 이 필터를 사용하여 빌드를 트리거할 수 있는 특정 사용자를 지정할 수 있습니다. 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 및 [Bitbucket Webhook 이벤트](bitbucket-webhook.md) 섹션을 참조하세요.

`FILE_PATH` 필터 설정  
프로젝트의 webhook 필터 그룹에 `FILE_PATH` 필터를 추가하여 변경 시 빌드를 트리거할 수 있는 파일을 포함하거나 제외합니다. 예를 들어 `excludeMatchedPattern` 속성과 함께 `^buildspec.yml$`과 같은 정규 표현식 패턴을 사용하여 `buildspec.yml` 파일 변경에 대한 빌드 요청을 거부할 수 있습니다. 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 및 [Bitbucket Webhook 이벤트](bitbucket-webhook.md) 섹션을 참조하세요.

빌드 IAM 역할의 권한 범위 좁히기  
webhook로 트리거되는 빌드는 프로젝트에 지정된 IAM 서비스 역할을 사용합니다. 서비스 역할의 권한을 빌드를 실행하는 데 필요한 최소 권한 세트로 설정하는 것이 좋습니다. 예를 들어 테스트 및 배포 시나리오에서는 테스트용 프로젝트 하나와 배포용 프로젝트 하나를 생성합니다. 테스트 프로젝트는 리포지토리의 webhook 빌드를 수락하지만 리소스에 대한 쓰기 권한은 제공하지 않습니다. 배포 프로젝트는 리소스에 대한 쓰기 권한을 제공하고 webhook 필터는 신뢰할 수 있는 사용자만 빌드를 트리거할 수 있도록 구성됩니다.

인라인 또는 Amazon S3 저장 buildspec 사용  
프로젝트 내에서 buildspec 인라인을 정의하거나 Amazon S3 버킷에 buildspec 파일을 저장하는 경우, buildspec 파일은 프로젝트 소유자만 볼 수 있습니다. 이렇게 하면 풀 요청이 buildspec 파일의 코드를 변경하여 원치 않는 빌드를 트리거하는 것을 방지할 수 있습니다. 자세한 내용은 CodeBuild API 참조의 [ProjectSource.buildspec](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html#CodeBuild-Type-ProjectSource-buildspec)을 참조하세요.**

# Bitbucket Webhook 이벤트
<a name="bitbucket-webhook"></a>

Webhook 필터 그룹을 사용하여 어느 Bitbucket Webhook 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 예를 들어 특정 분기가 변경된 경우에만 빌드가 트리거되도록 지정할 수 있습니다.

하나 이상의 웹후크 필터 그룹을 생성하여 어느 웹후크 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 필터 그룹이 true로 평가(그룹 내 모든 필터가 true로 평가)되면 빌드가 트리거됩니다. 필터 그룹을 생성할 때 다음을 지정합니다.

**이벤트**  
Bitbucket의 경우 다음 이벤트 중 하나 이상을 선택할 수 있습니다.  
+ `PUSH`
+ `PULL_REQUEST_CREATED`
+ `PULL_REQUEST_UPDATED`
+ `PULL_REQUEST_MERGED`
+ `PULL_REQUEST_CLOSED`
webhook의 이벤트 유형은 `X-Event-Key` 필드의 헤더에 있습니다. 다음 표에서는 `X-Event-Key` 헤더 값이 이벤트 유형에 매핑되는 방법을 보여 줍니다.  
`PULL_REQUEST_MERGED` 이벤트 유형을 사용하는 webhook 필터 그룹을 생성할 경우 Bitbucket webhook 설정의 `merged` 이벤트를 활성화해야 합니다. `PULL_REQUEST_CLOSED` 이벤트 유형을 사용하는 웹후크 필터 그룹을 생성할 경우 Bitbucket 웹후크 설정에서 `declined` 이벤트를 활성화해야 합니다.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/bitbucket-webhook.html)
`PULL_REQUEST_MERGED`의 경우 풀 요청이 스쿼시 전략에 병합되고 풀 요청 분기가 닫히면 원래의 풀 요청 커밋은 더 이상 존재하지 않게 됩니다. 이 경우 `CODEBUILD_WEBHOOK_MERGE_COMMIT` 환경 변수에는 스쿼시된 병합 커밋의 식별자가 포함됩니다.

**하나 이상의 선택적 필터**  
정규식을 사용하여 필터를 지정합니다. 이벤트가 빌드를 트리거하려면 연결된 그룹 내의 필터가 모두 true로 평가되어야 합니다.    
`ACTOR_ACCOUNT_ID`(콘솔의 `ACTOR_ID`)  
Bitbucket 계정 ID가 정규식 패턴과 일치하면 Webhook 이벤트가 빌드를 트리거합니다. Webhook 필터 페이로드에 있는 `actor` 객체의 `account_id` 속성에 이 값이 표시됩니다.  
`HEAD_REF`  
헤드 참조가 정규식 패턴(예: `refs/heads/branch-name` 및 `refs/tags/tag-name`)과 일치하면 webhook 이벤트가 빌드를 트리거합니다. `HEAD_REF` 필터가 브랜치나 태그의 Git 참조 이름을 평가합니다. Webhook 페이로드의 `push` 객체에 있는 `new` 객체의 `name` 필드에 브랜치 또는 태그 이름이 표시됩니다. pull 요청 이벤트의 경우 webhook 페이로드의 `source` 객체에 있는 `branch` 객체의 `name` 필드에 브랜치 이름이 표시됩니다.  
`BASE_REF`  
베이스 참조가 정규식 패턴과 일치하면 webhook 이벤트가 빌드를 트리거합니다. `BASE_REF` 필터는 풀 요청 이벤트에서만 작동합니다(예: `refs/heads/branch-name`). `BASE_REF` 필터가 브랜치의 Git 참조 이름을 평가합니다. Webhook 페이로드의 `destination` 객체에 있는 `branch` 객체의 `name` 필드에 브랜치 이름이 표시됩니다.  
`FILE_PATH`  
변경된 파일의 경로가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다.  
`COMMIT_MESSAGE`  
헤드 커밋 메시지가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다.  
`WORKFLOW_NAME`  
워크플로 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다.

**참고**  
Bitbucket 리포지토리의 webhook 설정에서 webhook 페이로드를 찾을 수 있습니다.

**Topics**
+ [Bitbucket Webhook 이벤트 필터링(콘솔)](bitbucket-webhook-events-console.md)
+ [Bitbucket Webhook 이벤트 필터링(SDK)](bitbucket-webhook-events-sdk.md)
+ [Bitbucket Webhook 이벤트 필터링(CloudFormation)](bitbucket-webhook-events-cfn.md)

# Bitbucket Webhook 이벤트 필터링(콘솔)
<a name="bitbucket-webhook-events-console"></a>

 AWS Management Console 를 사용하여 웹후크 이벤트를 필터링하려면: 

1.  프로젝트를 생성할 때 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.

1.  **이벤트 유형**에서 하나 이상의 이벤트를 선택합니다.

1.  이벤트가 빌드를 트리거할 때를 필터링하려면 **Start a build under these conditions(다음 조건에서 빌드를 시작)**에서 하나 이상의 선택적 필터를 추가합니다.

1.  이벤트가 트리거되지 않을 때를 필터링하려면 **Don't start a build under these conditions(다음 조건에서 빌드를 시작하지 않음)**에서 하나 이상의 선택적 필터를 추가합니다.

1.  **Add filter group(필터 그룹 추가)**를 선택하여 다른 필터 그룹을 추가합니다.

 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 *AWS CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.

이 예제에서는 Webhook 필터 그룹이 pull 요청에 대해서만 빌드를 트리거합니다.

![\[pull 요청에 대해서만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-bitbucket.png)


두 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/branch1!`와 일치하는 헤드 참조를 갖는 브랜치에서 생성 또는 업데이트된 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/branch1$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.

![\[두 필터 그룹의 예입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes-bitbucket.png)


이 예제에서는 Webhook 필터 그룹이 태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거합니다.

![\[태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude-bitbucket.png)


이 예제에서는 Webhook 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드를 트리거합니다.

![\[파일이 지정된 정규식과 일치하는 이름을 갖는 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex.png)


이 예제에서 Webhook 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경된 경우에만 빌드를 트리거합니다.

![\[파일이 지정된 폴더에서 변경된 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex.png)


이 예제에서는 Webhook 필터 그룹이 계정 ID가 정규식 `actor-account-id`와 일치하지 않는 Bitbucket 사용자가 변경을 수행한 경우에만 빌드를 트리거합니다.

**참고**  
 Bitbucket 계정 ID를 확인하는 자세한 방법은 https://api.bitbucket.org/2.0/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 Bitbucket 사용자 이름입니다.

![\[계정 ID가 없는 Bitbucket 사용자가 변경을 수행한 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-actor-bitbucket.png)


이 예제에서 webhook 필터 그룹은 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때 푸시 이벤트에 대한 빌드를 트리거합니다.

![\[헤드 커밋 메시지가 정규식과 일치할 때 푸시 이벤트에 대한 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message.png)


# Bitbucket Webhook 이벤트 필터링(SDK)
<a name="bitbucket-webhook-events-sdk"></a>

 AWS CodeBuild SDK를 사용하여 웹후크 이벤트를 필터링하려면 `CreateWebhook` 또는 `UpdateWebhook` API 메서드의 요청 구문에서 `filterGroups` 필드를 사용합니다. 자세한 내용은 *CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.

 pull 요청에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 요청 구문에 다음을 삽입합니다.

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
    }
  ]
]
```

 지정된 브랜치에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 `pattern` 파라미터를 사용하여 브랜치 이름을 필터링하는 정규식을 지정합니다. 두 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/myBranch$`와 일치하는 헤드 참조를 갖는 브랜치에서 생성 또는 업데이트된 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/myBranch$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_CLOSED"
    },
    {
      "type": "HEAD_REF",
      "pattern": "^refs/heads/myBranch$"
    },
    {
      "type": "BASE_REF",
      "pattern": "^refs/heads/main$"
    }
  ],
  [
    {
      "type": "EVENT",
      "pattern": "PUSH"
    },
    {
      "type": "HEAD_REF",
      "pattern": "^refs/heads/myBranch$"
    }
  ]
]
```

 `excludeMatchedPattern` 파라미터를 사용하여 빌드를 트리거하지 않을 이벤트를 지정할 수 있습니다. 이 예제에서는 태그 이벤트를 제외한 모든 요청에 대해 빌드가 트리거됩니다.

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
    },
    {
      "type": "HEAD_REF",
      "pattern": "^refs/tags/.*",
      "excludeMatchedPattern": true
    }
  ]
]
```

계정 ID가 `actor-account-id`인 Bitbucket 사용자가 변경을 수행한 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다.

**참고**  
 Bitbucket 계정 ID를 확인하는 자세한 방법은 https://api.bitbucket.org/2.0/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 Bitbucket 사용자 이름입니다.

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
    },
    {
      "type": "ACTOR_ACCOUNT_ID",
      "pattern": "actor-account-id"
    }
  ]
]
```

`pattern` 인수의 정규식과 일치하는 이름을 갖는 파일이 변경되는 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서는 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드가 트리거되도록 지정합니다.

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PUSH"
    },
    {
      "type": "FILE_PATH",
      "pattern": "^buildspec.*"
    }
  ]
]
```

이 예제에서 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경될 때만 빌드가 트리거되도록 지정합니다.

```
"filterGroups": [
    [
        {
            "type": "EVENT", 
            "pattern": "PUSH"
        },
        {
            "type": "FILE_PATH", 
            "pattern": "^src/.+|^test/.+"
        }
    ]
]
```

헤드 커밋 메시지가 패턴 인수의 정규식과 일치할 때만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서 필터 그룹은 푸시 이벤트의 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때만 빌드가 트리거되도록 지정합니다.

```
  "filterGroups": [
    [
      {
        "type": "EVENT",
        "pattern": "PUSH"
      },
      {
        "type": "COMMIT_MESSAGE",
        "pattern": "\[CodeBuild\]"
      }
    ]
  ]
```

# Bitbucket Webhook 이벤트 필터링(CloudFormation)
<a name="bitbucket-webhook-events-cfn"></a>

 CloudFormation 템플릿을 사용하여 웹후크 이벤트를 필터링하려면 AWS CodeBuild 프로젝트의 `FilterGroups` 속성을 사용합니다. 다음 CloudFormation 템플릿의 YAML 형식 부분은 두 개의 필터 그룹을 생성합니다. 이들은 하나 또는 둘 모두 true로 평가되면 빌드를 트리거합니다.
+  첫 번째 필터 그룹은 계정 ID가 `12345`와 일치하지 않는 Bitbucket 사용자가 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 생성 또는 업데이트한 pull 요청을 지정합니다.
+  두 번째 필터 그룹은 정규식 `^refs/heads/.*`와 일치하는 Git 참조 이름을 갖는 브랜치에서 생성되는 push 요청을 지정합니다.
+ 세 번째 필터 그룹은 정규식 `\[CodeBuild\]`와 일치하는 헤드 커밋 메시지에서 push 요청을 지정합니다.

```
CodeBuildProject:
  Type: AWS::CodeBuild::Project
  Properties:
    Name: MyProject
    ServiceRole: service-role
    Artifacts:
      Type: NO_ARTIFACTS
    Environment:
      Type: LINUX_CONTAINER
      ComputeType: BUILD_GENERAL1_SMALL
      Image: aws/codebuild/standard:5.0
    Source:
      Type: BITBUCKET
      Location: source-location
    Triggers:
      Webhook: true
      FilterGroups:
        - - Type: EVENT
            Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
          - Type: BASE_REF
            Pattern: ^refs/heads/main$
            ExcludeMatchedPattern: false
          - Type: ACTOR_ACCOUNT_ID
            Pattern: 12345
            ExcludeMatchedPattern: true
        - - Type: EVENT
            Pattern: PUSH
          - Type: HEAD_REF
            Pattern: ^refs/heads/.*
          - Type: FILE_PATH
            Pattern: READ_ME
            ExcludeMatchedPattern: true
        - - Type: EVENT
            Pattern: PUSH
          - Type: COMMIT_MESSAGE
            Pattern: \[CodeBuild\]
          - Type: FILE_PATH
            Pattern: ^src/.+|^test/.+
```

# GitHub 글로벌 및 조직 웹후크
<a name="github-global-organization-webhook"></a>

CodeBuild GitHub 글로벌 또는 조직 웹후크를 사용하여 GitHub 조직 또는 엔터프라이즈 내의 모든 리포지토리에서 웹후크 이벤트를 기반으로 빌드를 시작할 수 있습니다. 글로벌 및 조직 웹후크는 기존 GitHub 웹후크 이벤트 유형에서 작동하며 CodeBuild 웹후크를 생성할 때 범위 구성을 추가하여 구성할 수 있습니다. 글로벌 및 조직 웹후크를 사용하여 [ CodeBuild 내에서 자체 호스팅 GitHub Action 실행기를 설정](action-runner.md)하여 단일 프로젝트 내의 여러 리포지토리에서 `WORKFLOW_JOB_QUEUED` 이벤트를 수신할 수도 있습니다.

**Topics**
+ [글로벌 또는 조직 GitHub 웹후크 설정](github-global-organization-webhook-setup.md)
+ [GitHub 글로벌 또는 조직 웹후크 이벤트 필터링(콘솔)](github-global-organization-webhook-events-console.md)
+ [GitHub 조직 웹후크 이벤트 필터링(CloudFormation)](github-organization-webhook-events-cfn.md)

# 글로벌 또는 조직 GitHub 웹후크 설정
<a name="github-global-organization-webhook-setup"></a>

글로벌 또는 조직 GitHub 웹후크를 설정하는 상위 단계는 다음과 같습니다. 글로벌 및 조직 GitHub 웹후크에 대한 자세한 내용은 [GitHub 글로벌 및 조직 웹후크](github-global-organization-webhook.md) 섹션을 참조하세요.

1. 프로젝트의 소스 위치를 `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`으로 설정합니다.

1. 웹후크의 범위 구성에서 범위가 조직인지 [글로벌 웹후크](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/exploring-user-activity-in-your-enterprise/managing-global-webhooks)인지에 따라 `GITHUB_ORGANIZATION` 또는 `GITHUB_GLOBAL` 중 하나로 설정합니다. 자세한 내용은 [웹후크 유형](https://docs.github.com/en/webhooks/types-of-webhooks)을 참조하세요.

1. 웹후크의 범위 구성의 일부로 이름을 지정합니다. 조직 웹후크의 경우 조직 이름이고 글로벌 웹후크의 경우 엔터프라이즈 이름입니다.
**참고**  
프로젝트의 소스 유형이 `GITHUB_ENTERPRISE`인 경우 웹후크 범위 구성의 일부로 도메인을 지정해야 합니다.

1. (선택 사항) 조직 또는 엔터프라이즈 내의 특정 리포지토리에 대해서만 웹후크 이벤트를 수신하려면 웹후크를 생성할 때 `REPOSITORY_NAME`을 필터로 지정할 수 있습니다.

1. 조직 웹후크를 생성하는 경우 CodeBuild에 GitHub 내에서 조직 수준 웹후크를 생성할 수 있는 권한이 있는지 확인합니다. 조직 웹후크 권한을 사용하여 GitHub 개인 액세스 토큰을 생성하거나 CodeBuild OAuth를 사용할 수 있습니다. 자세한 내용은 [GitHub 및 GitHub Enterprise Server 액세스 토큰](access-tokens-github.md) 단원을 참조하십시오.

   조직 웹후크는 기존 GitHub 웹후크 이벤트 유형에서 작동합니다.

1. 글로벌 웹후크를 생성하는 경우 웹후크를 수동으로 생성해야 합니다. GitHub 내에서 웹후크를 수동으로 생성하는 방법에 대한 자세한 내용은 [GitHub 수동 웹후크](github-manual-webhook.md) 섹션을 참조하세요.

   글로벌 웹후크는 `WORKFLOW_JOB_QUEUED` 이벤트 유형만 지원합니다. 자세한 내용은 [자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md) 단원을 참조하십시오.

# GitHub 글로벌 또는 조직 웹후크 이벤트 필터링(콘솔)
<a name="github-global-organization-webhook-events-console"></a>

콘솔을 통해 GitHub 프로젝트를 생성할 때 다음 옵션을 선택하여 프로젝트 내에 GitHub 글로벌 또는 조직 웹후크를 생성합니다. 글로벌 및 조직 GitHub 웹후크에 대한 자세한 내용은 [GitHub 글로벌 및 조직 웹후크](github-global-organization-webhook.md) 섹션을 참조하세요.

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.

1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
   +  **소스**에서 다음과 같이 합니다.
     +  **소스 공급자**에서 **GitHub** 또는 **GitHub Enterprise**를 선택합니다.
     +  **리포지토리**에서 **GitHub 범위 웹후크**를 선택합니다.

        GitHub 리포지토리는 자동으로 `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`으로 설정되며, 이는 글로벌 및 조직 웹후크에 필요한 소스 위치입니다.
**참고**  
조직 웹후크를 사용하는 경우 CodeBuild에 GitHub 내에서 조직 수준 웹후크를 생성할 수 있는 권한이 있는지 확인합니다. [기존 OAuth 연결](oauth-app-github.md)을 사용하는 경우 CodeBuild에 이 권한을 부여하려면 연결을 다시 생성해야 할 수 있습니다. 또는 [CodeBuild 수동 웹후크 기능](github-manual-webhook.md)을 사용하여 수동으로 웹후크를 생성할 수 있습니다. 기존 GitHub OAuth 토큰이 있고 조직 권한을 추가하려는 경우 [OAuth 토큰의 권한을 취소](https://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-apps)하고 CodeBuild 콘솔을 통해 토큰을 다시 연결할 수 있습니다.  
![\[GitHub 범위 웹후크의 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-organization-webhook-source.png)
   +  **기본 소스 웹후크 이벤트**에서: 
     +  **범위 유형 **에서 조직 웹후크를 생성하는 경우 **조직 수준**을 선택하고 글로벌 웹후크를 생성하는 경우 **엔터프라이즈 수준**을 선택합니다.
     +  웹후크가 글로벌 웹후크인지 아니면 조직 웹후크인지에 따라 **이름**에 엔터프라이즈 또는 조직 이름을 입력합니다.

       프로젝트의 소스 유형이 `GITHUB_ENTERPRISE`인 경우 웹후크 조직 구성의 일부로 도메인을 지정해야 합니다. 예를 들어 조직의 URL이 **https://domain.com/orgs/org-name**인 경우 도메인은 **https://domain.com**입니다.
**참고**  
 웹후크가 생성된 후에는 이 이름을 변경할 수 없습니다. 이름을 변경하려면 웹후크를 삭제하고 다시 생성할 수 있습니다. 웹후크를 완전히 제거하려면 프로젝트 소스 위치를 GitHub 리포지토리로 업데이트할 수도 있습니다.  
![\[글로벌 또는 조직 웹후크의 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-organization-webhook-primary-events.png)
     +  (선택 사항) **웹후크 이벤트 필터 그룹**에서 [새 빌드를 트리거할 이벤트](github-webhook.md)를 지정할 수 있습니다. 특정 리포지토리의 웹후크 이벤트에서만 빌드를 트리거하는 필터로 `REPOSITORY_NAME`을 지정할 수도 있습니다.  
![\[특정 리포지토리의 웹후크 이벤트에서만 빌드를 트리거하는 필터입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-organization-webhook-filter-groups.png)

       이벤트 유형을 `WORKFLOW_JOB_QUEUED`로 설정하여 자체 호스팅 GitHub Action 실행기를 설정할 수도 있습니다. 자세한 내용은 [자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md) 단원을 참조하십시오.

1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다.

# GitHub 조직 웹후크 이벤트 필터링(CloudFormation)
<a name="github-organization-webhook-events-cfn"></a>

 CloudFormation 템플릿을 사용하여 조직 웹후크 이벤트를 필터링하려면 프로젝트의 `ScopeConfiguration` 속성을 사용합니다 AWS CodeBuild . 글로벌 및 조직 GitHub 웹후크에 대한 자세한 내용은 [GitHub 글로벌 및 조직 웹후크](github-global-organization-webhook.md) 섹션을 참조하세요.

**참고**  
글로벌 웹후크 및 GitHub Enterprise 웹후크는에서 지원되지 않습니다 CloudFormation.

 CloudFormation 템플릿의 다음 YAML 형식 부분은 4개의 필터 그룹을 생성합니다. 이들은 하나 또는 모두 true로 평가되면 빌드를 트리거합니다.
+  첫 번째 필터 그룹은 계정 ID가 `12345`와 일치하지 않는 GitHub 사용자가 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 생성 또는 업데이트한 pull 요청을 지정합니다.
+  두 번째 필터 그룹은 정규식 `^refs/heads/.*`와 일치하는 Git 참조 이름을 갖는 브랜치에서 정규식 `READ_ME`와 일치하는 이름을 갖는 파일에 생성되는 push 요청을 지정합니다.
+ 세 번째 필터 그룹은 정규식 `\[CodeBuild\]`와 일치하는 헤드 커밋 메시지에서 push 요청을 지정합니다.
+ 네 번째 필터 그룹은 정규식 `\[CI-CodeBuild\]`와 일치하는 워크플로 이름을 가진 GitHub Action 워크플로 작업 요청을 지정합니다.

```
CodeBuildProject:
  Type: AWS::CodeBuild::Project
  Properties:
    Name: MyProject
    ServiceRole: service-role
    Artifacts:
      Type: NO_ARTIFACTS
    Environment:
      Type: LINUX_CONTAINER
      ComputeType: BUILD_GENERAL1_SMALL
      Image: aws/codebuild/standard:5.0
    Source:
      Type: GITHUB
      Location: source-location
    Triggers:
      Webhook: true
      ScopeConfiguration:
        Name: organization-name
        Scope: GITHUB_ORGANIZATION
      FilterGroups:
        - - Type: EVENT
            Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
          - Type: BASE_REF
            Pattern: ^refs/heads/main$
            ExcludeMatchedPattern: false
          - Type: ACTOR_ACCOUNT_ID
            Pattern: 12345
            ExcludeMatchedPattern: true
        - - Type: EVENT
            Pattern: PUSH
          - Type: HEAD_REF
            Pattern: ^refs/heads/.*
          - Type: FILE_PATH
            Pattern: READ_ME
            ExcludeMatchedPattern: true
        - - Type: EVENT
            Pattern: PUSH
          - Type: COMMIT_MESSAGE
            Pattern: \[CodeBuild\]
          - Type: FILE_PATH
            Pattern: ^src/.+|^test/.+
        - - Type: EVENT
            Pattern: WORKFLOW_JOB_QUEUED
          - Type: WORKFLOW_NAME
            Pattern: \[CI-CodeBuild\]
```

# GitHub 수동 웹후크
<a name="github-manual-webhook"></a>

CodeBuild가 GitHub 내에서 웹후크를 자동으로 생성하려고 시도하지 않도록 수동 GitHub 웹후크를 구성할 수 있습니다. CodeBuild는 호출의 일부로 페이로드 URL을 반환하여 웹후크를 생성하고 GitHub 내에서 웹후크를 수동으로 생성하는 데 사용할 수 있습니다. CodeBuild가 GitHub 계정에서 웹후크를 생성할 수 있는 허용 목록에 없는 경우에도 빌드 프로젝트의 웹후크를 수동으로 생성할 수 있습니다.

다음 절차에 따라 GitHub 수동 웹후크를 생성합니다.

**GitHub 수동 웹후크를 생성하려면**

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.

1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
   +  **소스**에서 다음과 같이 합니다.
     +  **소스 공급자**에서 **GitHub**를 선택합니다.
     +  **리포지토리**에 대해 **내 GitHub 계정의 리포지토리**를 선택합니다.
     +  **리포지토리 URL**에 **https://github.com/*user-name*/*repository-name***을 입력합니다.
   +  **기본 소스 웹후크 이벤트**에서: 
     +  **웹후크 - 선택 사항**에서 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.
     +  **추가 구성** 및 **수동 생성 - 선택 사항**을 선택하고 **GitHub 콘솔에서 이 리포지토리에 대한 웹후크 수동 생성**을 선택합니다.

1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다. 나중에 사용할 **페이로드 URL** 및 **보안 암호** 값을 기록해 둡니다.  
![\[수동 웹후크에 대한 페이로드 URL 및 보안 암호 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-manual-webhook-values.png)

1. `https://github.com/user-name/repository-name/settings/hooks`에서 GitHub 콘솔을 열고 **웹후크 추가**를 선택합니다.
   + **페이로드 URL**에 앞서 기록한 페이로드 URL 값을 입력합니다.
   + **콘텐츠 유형**에 대해 **application/json**을 선택합니다.
   + **보안 암호**에 앞서 기록한 보안 암호 값을 입력합니다.
   + CodeBuild로 웹후크 페이로드를 전송할 개별 이벤트를 구성합니다. **이 웹후크를 트리거할 이벤트는 무엇입니까?**에서 **개별 이벤트 선택**을 선택한 다음, **푸시**, **Pull 요청** 및 **릴리스** 이벤트 중에서 선택합니다. `WORKFLOW_JOB_QUEUED` 이벤트에 대한 빌드를 시작하려면 **워크플로 작업**을 선택합니다. GitHub Action 실행기에 대한 자세한 내용은 [자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md) 섹션을 참조하세요. CodeBuild에서 지원하는 이벤트 유형에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.

1. **웹후크 추가**를 선택합니다.

# GitHub Webhook 이벤트
<a name="github-webhook"></a>

Webhook 필터 그룹을 사용하여 어느 GitHub Webhook 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 예를 들어 특정 분기가 변경된 경우에만 빌드가 트리거되도록 지정할 수 있습니다.

하나 이상의 웹후크 필터 그룹을 생성하여 어느 웹후크 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 필터 그룹이 true로 평가(그룹 내 모든 필터가 true로 평가)되면 빌드가 트리거됩니다. 필터 그룹을 생성할 때 다음을 지정합니다.

**이벤트**  
GitHub의 경우 `PUSH`, `PULL_REQUEST_CREATED`, `PULL_REQUEST_UPDATED`, `PULL_REQUEST_REOPENED`, `PULL_REQUEST_MERGED`, `PULL_REQUEST_CLOSED`, `RELEASED`, `PRERELEASED` 및 `WORKFLOW_JOB_QUEUED` 이벤트 가운데 하나 이상을 선택할 수 있습니다. webhook 이벤트 유형은 webhook 페이로드의 `X-GitHub-Event` 헤더에 있습니다. `X-GitHub-Event` 헤더에서 `pull_request` 또는 `push`를 볼 수 있습니다. 풀 요청 이벤트의 경우 유형은 webhook 이벤트 페이로드의 `action` 필드에 있습니다. 다음 표에서는 `X-GitHub-Event` 헤더 값과 webhook 풀 요청 페이로드 `action` 필드 값이 사용 가능한 이벤트 유형에 매핑되는 방법을 보여 줍니다.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/github-webhook.html)
 GitHub 및 GitHub Enterprise Server에서만 `PULL_REQUEST_REOPENED` 이벤트 유형을 사용할 수 있습니다. GitHub에서만 `RELEASED` 및 `PRERELEASED` 이벤트 유형을 사용할 수 있습니다. `WORKFLOW_JOB_QUEUED`에 대한 자세한 내용은 [자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md) 섹션을 참조하세요.

**하나 이상의 선택적 필터**  
정규식을 사용하여 필터를 지정합니다. 이벤트가 빌드를 트리거하려면 연결된 그룹 내의 필터가 모두 true로 평가되어야 합니다.    
`ACTOR_ACCOUNT_ID`(콘솔의 `ACTOR_ID`)  
GitHub 또는 GitHub Enterprise Server 계정 ID가 정규식 패턴과 일치하면 Webhook 이벤트가 빌드를 트리거합니다. webhook 페이로드에 있는 `sender` 객체의 `id` 속성에서 이 값을 찾을 수 있습니다.  
`HEAD_REF`  
헤드 참조가 정규식 패턴(예: `refs/heads/branch-name` 또는 `refs/tags/tag-name`)과 일치하면 webhook 이벤트가 빌드를 트리거합니다. 푸시 이벤트의 경우 webhook 페이로드의 `ref` 속성에서 참조 이름을 찾을 수 있습니다. 풀 요청 이벤트의 경우 webhook 페이로드에 있는 `head` 객체의 `ref` 속성에서 브랜치 이름을 찾을 수 있습니다.  
`BASE_REF`  
기본 참조가 정규식 패턴(예: `refs/heads/branch-name`)과 일치하면 webhook 이벤트가 빌드를 트리거합니다. 풀 요청 이벤트에서만 `BASE_REF` 필터를 사용할 수 있습니다. webhook 페이로드에 있는 `base` 객체의 `ref` 속성에서 브랜치 이름을 찾을 수 있습니다.  
`FILE_PATH`  
변경된 파일의 경로가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다. `FILE_PATH` 필터는 GitHub push 및 pull 요청 이벤트와 GitHub Enterprise Server push 이벤트에서 사용할 수 있습니다. GitHub Enterprise Server pull 요청 이벤트에서는 사용할 수 없습니다.  
`COMMIT_MESSAGE`  
헤드 커밋 메시지가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다. `COMMIT_MESSAGE` 필터는 GitHub push 및 pull 요청 이벤트와 GitHub Enterprise Server push 이벤트에서 사용할 수 있습니다. GitHub Enterprise Server pull 요청 이벤트에서는 사용할 수 없습니다.  
`TAG_NAME`  
릴리스의 태그 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다. `TAG_NAME` 필터는 GitHub 릴리스 및 사전 릴리스된 요청 이벤트와 함께 사용할 수 있습니다.  
`RELEASE_NAME`  
릴리스 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다. `RELEASE_NAME` 필터는 GitHub 릴리스 및 사전 릴리스된 요청 이벤트와 함께 사용할 수 있습니다.  
`REPOSITORY_NAME`  
리포지토리 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다. `REPOSITORY_NAME` 필터는 GitHub 글로벌 또는 조직 웹후크에서만 사용할 수 있습니다.  
`ORGANIZATION_NAME`  
조직 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다. `ORGANIZATION_NAME` 필터는 GitHub 글로벌 웹후크에서만 사용할 수 있습니다.  
`WORKFLOW_NAME`  
워크플로 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다. `WORKFLOW_NAME` 필터는 GitHub Action 워크플로 작업 대기열 요청 이벤트와 함께 사용할 수 있습니다.

**참고**  
GitHub 리포지토리의 webhook 설정에서 webhook 페이로드를 찾을 수 있습니다.

**Topics**
+ [GitHub Webhook 이벤트 필터링(콘솔)](github-webhook-events-console.md)
+ [GitHub Webhook 이벤트 필터링(SDK)](github-webhook-events-sdk.md)
+ [GitHub Webhook 이벤트 필터링(CloudFormation)](github-webhook-events-cfn.md)

# GitHub Webhook 이벤트 필터링(콘솔)
<a name="github-webhook-events-console"></a>

다음 지침에 따라 AWS Management Console을 사용하여 GitHub 웹후크 이벤트를 필터링합니다. GitHub 웹후크 이벤트 유형에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.

**기본 소스 webhook 이벤트**에서 다음을 선택합니다. 이 섹션은 소스 리포지토리로 **GitHub 계정의 리포지토리**를 선택한 경우에만 사용할 수 있습니다.

1. 프로젝트를 생성할 때 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.

1. **이벤트 유형**에서 하나 이상의 이벤트를 선택합니다.

1. 이벤트가 빌드를 트리거할 때를 필터링하려면 **Start a build under these conditions(다음 조건에서 빌드를 시작)**에서 하나 이상의 선택적 필터를 추가합니다.

1. 이벤트가 트리거되지 않을 때를 필터링하려면 **Don't start a build under these conditions(다음 조건에서 빌드를 시작하지 않음)**에서 하나 이상의 선택적 필터를 추가합니다.

1. 필요한 경우 **필터 그룹 추가**를 선택하여 다른 필터 그룹을 추가합니다.

 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 *AWS CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.

이 예제에서는 Webhook 필터 그룹이 pull 요청에 대해서만 빌드를 트리거합니다.

![\[pull 요청에 대해서만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter.png)


두 Webhook 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/branch1$`와 일치하는 헤드 참조를 갖는 브랜치에서 생성되거나 업데이트되거나 다시 열린 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/branch1$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.

![\[두 필터 그룹의 예입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes.png)


이 예제에서는 Webhook 필터 그룹이 태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거합니다.

![\[태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude.png)


이 예제에서는 Webhook 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드를 트리거합니다.

![\[파일이 지정된 정규식과 일치하는 이름을 갖는 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex.png)


이 예제에서 Webhook 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경된 경우에만 빌드를 트리거합니다.

![\[파일이 지정된 폴더에서 변경된 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex.png)


이 예제에서는 Webhook 필터 그룹이 계정 ID가 정규식 `actor-account-id`와 일치하는 지정된 GitHub 또는 GitHub Enterprise Server 사용자가 변경을 수행한 경우에만 빌드를 트리거합니다.

**참고**  
 GitHub 계정 ID를 확인하는 자세한 방법은 https://api.github.com/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 GitHub 사용자 이름입니다.

![\[정규식과 일치하는 계정 ID를 가진 지정된 GitHub 사용자가 변경을 수행한 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-actor.png)


이 예제에서 webhook 필터 그룹은 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때 푸시 이벤트에 대한 빌드를 트리거합니다.

![\[헤드 커밋 메시지가 정규식과 일치할 때 푸시 이벤트에 대한 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message.png)


이 예제에서는 웹후크 필터 그룹이 GitHub Action 워크플로 작업 이벤트에 대한 빌드만 트리거합니다.

**참고**  
CodeBuild는 웹후크에 **WORKFLOW\$1JOB\$1QUEUED** 이벤트 필터가 포함된 필터 그룹이 있는 경우에만 GitHub Action 워크플로 작업을 처리합니다.

![\[웹후크 필터 그룹은 GitHub Actions 워크플로 작업 이벤트에 대해서만 빌드를 트리거합니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-actions-workflow-job-queued-no-highlight.png)


이 예제에서 웹후크 필터 그룹은 정규식 `CI-CodeBuild`와 일치하는 워크플로 이름에 대한 빌드를 트리거합니다.

![\[웹후크 필터 그룹은 정규식과 일치하는 워크플로 이름에 대한 빌드를 트리거합니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-actions-workflow-job-specific.png)


# GitHub Webhook 이벤트 필터링(SDK)
<a name="github-webhook-events-sdk"></a>

 AWS CodeBuild SDK를 사용하여 웹후크 이벤트를 필터링하려면 `CreateWebhook` 또는 `UpdateWebhook` API 메서드의 요청 구문에서 `filterGroups` 필드를 사용합니다. 자세한 내용은 *CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.

GitHub 웹후크 이벤트 유형에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.

 pull 요청에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 요청 구문에 다음을 삽입합니다.

```
"filterGroups": [
   [
        {
            "type": "EVENT", 
            "pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
        }
    ]
]
```

 지정된 브랜치에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 `pattern` 파라미터를 사용하여 브랜치 이름을 필터링하는 정규식을 지정합니다. 두 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/myBranch$`와 일치하는 헤드 참조를 갖는 브랜치에서 생성되거나 업데이트되거나 다시 열린 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/myBranch$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.

```
"filterGroups": [
    [
        {
            "type": "EVENT", 
            "pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED"
        },
        {
            "type": "HEAD_REF", 
            "pattern": "^refs/heads/myBranch$"
        },
        {
            "type": "BASE_REF", 
            "pattern": "^refs/heads/main$"
        }
    ],
    [
        {
            "type": "EVENT", 
            "pattern": "PUSH"
        },
        {
            "type": "HEAD_REF", 
            "pattern": "^refs/heads/myBranch$"
        }
    ]
]
```

 `excludeMatchedPattern` 파라미터를 사용하여 빌드를 트리거하지 않을 이벤트를 지정할 수 있습니다. 예를 들어 이 예제에서는 태그 이벤트를 제외한 모든 요청에 대해 빌드가 트리거됩니다.

```
"filterGroups": [
    [
        {
            "type": "EVENT", 
            "pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
        },
        {
            "type": "HEAD_REF", 
            "pattern": "^refs/tags/.*", 
            "excludeMatchedPattern": true
        }
    ]
]
```

`pattern` 인수의 정규식과 일치하는 이름을 갖는 파일이 변경되는 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서는 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드가 트리거되도록 지정합니다.

```
"filterGroups": [
    [
        {
            "type": "EVENT", 
            "pattern": "PUSH"
        },
        {
            "type": "FILE_PATH", 
            "pattern": "^buildspec.*"
        }
    ]
]
```

이 예제에서 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경될 때만 빌드가 트리거되도록 지정합니다.

```
"filterGroups": [
    [
        {
            "type": "EVENT", 
            "pattern": "PUSH"
        },
        {
            "type": "FILE_PATH", 
            "pattern": "^src/.+|^test/.+"
        }
    ]
]
```

계정 ID가 `actor-account-id`인 지정된 GitHub 또는 GitHub Enterprise Server 사용자가 변경을 수행한 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다.

**참고**  
 GitHub 계정 ID를 확인하는 자세한 방법은 https://api.github.com/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 GitHub 사용자 이름입니다.

```
"filterGroups": [
    [
        {
            "type": "EVENT", 
            "pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
        },
        {
            "type": "ACTOR_ACCOUNT_ID", 
            "pattern": "actor-account-id"
        }
    ]
]
```

헤드 커밋 메시지가 패턴 인수의 정규식과 일치할 때만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서 필터 그룹은 푸시 이벤트의 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때만 빌드가 트리거되도록 지정합니다.

```
"filterGroups": [
    [
        {
            "type": "EVENT",
            "pattern": "PUSH"
        },
        {
            "type": "COMMIT_MESSAGE",
            "pattern": "\[CodeBuild\]"
        }
    ]
]
```

GitHub Action 워크플로에 대한 빌드를 트리거하는 웹후크 필터를 생성하려면 요청 구문에 다음을 삽입합니다.

```
"filterGroups": [
   [
        {
            "type": "EVENT", 
            "pattern": "WORKFLOW_JOB_QUEUED"
        }
    ]
]
```

# GitHub Webhook 이벤트 필터링(CloudFormation)
<a name="github-webhook-events-cfn"></a>

 CloudFormation 템플릿을 사용하여 웹후크 이벤트를 필터링하려면 AWS CodeBuild 프로젝트의 `FilterGroups` 속성을 사용합니다.

GitHub 웹후크 이벤트 유형에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.

다음 CloudFormation 템플릿의 YAML 형식 부분은 두 개의 필터 그룹을 생성합니다. 이들은 하나 또는 둘 모두 true로 평가되면 빌드를 트리거합니다.
+  첫 번째 필터 그룹은 계정 ID가 `12345`와 일치하지 않는 GitHub 사용자가 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 생성 또는 업데이트한 pull 요청을 지정합니다.
+  두 번째 필터 그룹은 정규식 `^refs/heads/.*`와 일치하는 Git 참조 이름을 갖는 브랜치에서 정규식 `READ_ME`와 일치하는 이름을 갖는 파일에 생성되는 push 요청을 지정합니다.
+ 세 번째 필터 그룹은 정규식 `\[CodeBuild\]`와 일치하는 헤드 커밋 메시지에서 push 요청을 지정합니다.
+ 네 번째 필터 그룹은 정규식 `\[CI-CodeBuild\]`와 일치하는 워크플로 이름을 가진 GitHub Action 워크플로 작업 요청을 지정합니다.

```
CodeBuildProject:
  Type: AWS::CodeBuild::Project
  Properties:
    Name: MyProject
    ServiceRole: service-role
    Artifacts:
      Type: NO_ARTIFACTS
    Environment:
      Type: LINUX_CONTAINER
      ComputeType: BUILD_GENERAL1_SMALL
      Image: aws/codebuild/standard:5.0
    Source:
      Type: GITHUB
      Location: source-location
    Triggers:
      Webhook: true
      FilterGroups:
        - - Type: EVENT
            Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
          - Type: BASE_REF
            Pattern: ^refs/heads/main$
            ExcludeMatchedPattern: false
          - Type: ACTOR_ACCOUNT_ID
            Pattern: 12345
            ExcludeMatchedPattern: true
        - - Type: EVENT
            Pattern: PUSH
          - Type: HEAD_REF
            Pattern: ^refs/heads/.*
          - Type: FILE_PATH
            Pattern: READ_ME
            ExcludeMatchedPattern: true
        - - Type: EVENT
            Pattern: PUSH
          - Type: COMMIT_MESSAGE
            Pattern: \[CodeBuild\]
          - Type: FILE_PATH
            Pattern: ^src/.+|^test/.+
        - - Type: EVENT
            Pattern: WORKFLOW_JOB_QUEUED
          - Type: WORKFLOW_NAME
            Pattern: \[CI-CodeBuild\]
```

# GitLab 그룹 웹후크
<a name="gitlab-group-webhook"></a>

CodeBuild GitLab 그룹 웹후크를 사용하여 GitLab 그룹 내의 모든 리포지토리에서 웹후크 이벤트를 기반으로 빌드를 시작할 수 있습니다. 그룹 웹후크는 기존 GitLab 웹후크 이벤트 유형에서 작동하며 CodeBuild 웹후크를 생성할 때 범위 구성을 추가하여 구성할 수 있습니다. 그룹 웹후크를 사용하여 [CodeBuild 내에서 자체 호스팅 GitLab 실행기를 설정](gitlab-runner.md)하여 단일 프로젝트 내의 여러 리포지토리에서 `WORKFLOW_JOB_QUEUED` 이벤트를 수신할 수도 있습니다.

**Topics**
+ [그룹 GitLab 웹후크 설정](gitlab-group-webhook-setup.md)
+ [GitLab 그룹 웹후크 이벤트 필터링(콘솔)](gitlab-group-webhook-events-console.md)
+ [GitLab 그룹 웹후크 이벤트 필터링(CloudFormation)](gitlab-group-webhook-events-cfn.md)

# 그룹 GitLab 웹후크 설정
<a name="gitlab-group-webhook-setup"></a>

그룹 GitLab 웹후크를 설정하는 상위 단계는 다음과 같습니다. 그룹 GitLab 웹후크에 대한 자세한 내용은 [GitLab 그룹 웹후크](gitlab-group-webhook.md) 섹션을 참조하세요.

1. 프로젝트의 소스 위치를 `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`으로 설정합니다.

1. 웹후크의 범위 구성에서 범위를 `GITLAB_GROUP`으로 설정합니다.

1. 웹후크의 범위 구성의 일부로 이름을 지정합니다. 그룹 웹후크의 경우 그룹 이름입니다.
**참고**  
프로젝트의 소스 유형이 `GITLAB_SELF_MANAGED`인 경우 웹후크 범위 구성의 일부로 도메인을 지정해야 합니다.

1. (선택 사항) 조직 또는 엔터프라이즈 내의 특정 리포지토리에 대해서만 웹후크 이벤트를 수신하려면 웹후크를 생성할 때 `REPOSITORY_NAME`을 필터로 지정할 수 있습니다.

1. 그룹 웹후크를 생성할 때 CodeBuild에 GitLab 내에서 그룹 수준 웹후크를 생성할 권한이 있는지 확인합니다. 이를 위해 CodeConnections를 통해 CodeBuild OAuth를 사용할 수 있습니다. 자세한 내용은 [CodeBuild의 GitLab 액세스](access-tokens-gitlab-overview.md) 단원을 참조하십시오.

   그룹 웹후크는 기존 GitLab 웹후크 이벤트 유형에서 작동합니다.

# GitLab 그룹 웹후크 이벤트 필터링(콘솔)
<a name="gitlab-group-webhook-events-console"></a>

콘솔을 통해 GitLab 프로젝트를 생성할 때 다음 옵션을 선택하여 프로젝트 내에 GitLab 그룹 웹후크를 생성합니다. 그룹 GitLab 웹후크에 대한 자세한 내용은 [GitLab 그룹 웹후크](gitlab-group-webhook.md) 섹션을 참조하세요.

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.

1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
   +  **소스**에서 다음과 같이 합니다.
     +  **소스 공급자**에서 **GitLab** 또는 **GitLab Self Managed**를 선택합니다.
     +  **리포지토리**에서 **GitLab 범위 웹후크**를 선택합니다.

        GitLab 리포지토리는 그룹 웹후크에 필요한 소스 위치인 `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`으로 자동 설정됩니다.
**참고**  
그룹 웹후크를 사용하는 경우 CodeBuild에 GitLab 내에서 그룹 수준 웹후크를 생성할 수 있는 권한이 있는지 확인합니다. [기존 OAuth 연결](access-tokens-gitlab-overview.md#connections-gitlab)을 사용하는 경우 CodeBuild에 이 권한을 부여하려면 연결을 다시 생성해야 할 수 있습니다.  
![\[GitLab 범위 웹후크의 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/gitlab-group-source.png)
   +  **기본 소스 웹후크 이벤트**에서: 
     +  **그룹 이름**에 그룹 이름을 입력합니다.

       프로젝트의 소스 유형이 `GITLAB_SELF_MANAGED`인 경우 웹후크 그룹 구성의 일부로 도메인을 지정해야 합니다. 예를 들어 그룹의 URL이 **https://domain.com/group/group-name**인 경우 도메인은 **https://domain.com**입니다.
**참고**  
 웹후크가 생성된 후에는 이 이름을 변경할 수 없습니다. 이름을 변경하려면 웹후크를 삭제하고 다시 생성할 수 있습니다. 웹후크를 완전히 제거하려면 프로젝트 소스 위치를 GitLab 리포지토리로 업데이트할 수도 있습니다.  
![\[그룹 웹후크의 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/gitlab-group-webhook-primary-events.png)
     +  (선택 사항) **웹후크 이벤트 필터 그룹**에서 [새 빌드를 트리거할 이벤트](gitlab-webhook.md)를 지정할 수 있습니다. 특정 리포지토리의 웹후크 이벤트에서만 빌드를 트리거하는 필터로 `REPOSITORY_NAME`을 지정할 수도 있습니다.  
![\[특정 리포지토리의 웹후크 이벤트에서만 빌드를 트리거하는 필터입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-organization-webhook-filter-groups.png)

       이벤트 유형을 `WORKFLOW_JOB_QUEUED`로 설정하여 자체 호스팅 GitLab 실행기를 설정할 수도 있습니다. 자세한 내용은 [의 자체 관리형 GitLab 실행기 AWS CodeBuild](gitlab-runner.md) 단원을 참조하십시오.

1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다.

# GitLab 그룹 웹후크 이벤트 필터링(CloudFormation)
<a name="gitlab-group-webhook-events-cfn"></a>

 CloudFormation 템플릿을 사용하여 그룹 웹후크 이벤트를 필터링하려면 프로젝트의 `ScopeConfiguration` 속성을 사용합니다 AWS CodeBuild . 그룹 GitLab 웹후크에 대한 자세한 내용은 [GitLab 그룹 웹후크](gitlab-group-webhook.md) 섹션을 참조하세요.

 CloudFormation 템플릿의 다음 YAML 형식 부분은 4개의 필터 그룹을 생성합니다. 이들은 하나 또는 모두 true로 평가되면 빌드를 트리거합니다.
+  첫 번째 필터 그룹은 계정 ID가 `12345`와 일치하지 않는 GitLab 사용자가 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름을 갖는 분기에서 생성 또는 업데이트한 pull 요청을 지정합니다.
+  두 번째 필터 그룹은 정규식 `^refs/heads/.*`와 일치하는 Git 참조 이름을 갖는 브랜치에서 정규식 `READ_ME`와 일치하는 이름을 갖는 파일에 생성되는 push 요청을 지정합니다.
+ 세 번째 필터 그룹은 정규식 `\[CodeBuild\]`와 일치하는 헤드 커밋 메시지에서 push 요청을 지정합니다.
+ 네 번째 필터 그룹은 정규식 `\[CI-CodeBuild\]`와 일치하는 CI/CD 파이프라인 이름이 있는 GitLab CI/CD 파이프라인 작업 요청을 지정합니다.

```
CodeBuildProject:
  Type: AWS::CodeBuild::Project
  Properties:
    Name: MyProject
    ServiceRole: service-role
    Artifacts:
      Type: NO_ARTIFACTS
    Environment:
      Type: LINUX_CONTAINER
      ComputeType: BUILD_GENERAL1_SMALL
      Image: aws/codebuild/standard:5.0
    Source:
      Type: GITLAB
      Location: source-location
    Triggers:
      Webhook: true
      ScopeConfiguration:
        Name: group-name
        Scope: GITLAB_GROUP
      FilterGroups:
        - - Type: EVENT
            Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
          - Type: BASE_REF
            Pattern: ^refs/heads/main$
            ExcludeMatchedPattern: false
          - Type: ACTOR_ACCOUNT_ID
            Pattern: 12345
            ExcludeMatchedPattern: true
        - - Type: EVENT
            Pattern: PUSH
          - Type: HEAD_REF
            Pattern: ^refs/heads/.*
          - Type: FILE_PATH
            Pattern: READ_ME
            ExcludeMatchedPattern: true
        - - Type: EVENT
            Pattern: PUSH
          - Type: COMMIT_MESSAGE
            Pattern: \[CodeBuild\]
          - Type: FILE_PATH
            Pattern: ^src/.+|^test/.+
        - - Type: EVENT
            Pattern: WORKFLOW_JOB_QUEUED
          - Type: WORKFLOW_NAME
            Pattern: \[CI-CodeBuild\]
```

# GitLab 수동 웹후크
<a name="gitlab-manual-webhook"></a>

CodeBuild가 GitLab 내에서 웹후크를 자동으로 생성하려고 시도하지 않도록 수동 GitLab 웹후크를 구성할 수 있습니다. CodeBuild는 직접 호출의 일부로 페이로드 URL을 반환하여 웹후크를 생성하고 GitLab 내에서 웹후크를 수동으로 생성하는 데 사용할 수 있습니다. CodeBuild가 GitLab 계정에서 웹후크를 생성할 수 있는 허용 목록에 없는 경우에도 빌드 프로젝트의 웹후크를 수동으로 생성할 수 있습니다.

다음 절차에 따라 GitLab 수동 웹후크를 생성합니다.

**GitLab 수동 웹후크를 생성하려면**

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)에서 AWS CodeBuild 콘솔을 엽니다.

1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
   +  **소스**에서 다음과 같이 합니다.
     +  **소스 공급자**에서 **GitLab**을 선택합니다.
     +  **리포지토리**에 대해 **내 GitLab 계정의 리포지토리**를 선택합니다.
     +  **리포지토리 URL**에 **https://gitlab.com/*user-name*/*repository-name***을 입력합니다.
   +  **기본 소스 웹후크 이벤트**에서: 
     +  **웹후크 - 선택 사항**에서 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.
     +  **추가 구성** 및 **수동 생성 - 선택 사항**을 선택하고 **GitLab 콘솔에서 이 리포지토리에 대한 웹후크 수동 생성**을 선택합니다.

1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다. 나중에 사용할 **페이로드 URL** 및 **보안 암호** 값을 기록해 둡니다.

1. `https://gitlab.com/user-name/repository-name/-/hooks`에서 GitLab 콘솔을 열고 **새 웹후크 추가**를 선택합니다.
   + **URL**에 앞서 기록한 페이로드 URL 값을 입력합니다.
   + **보안 암호 토큰**에 앞서 기록한 보안 암호 값을 입력합니다.
   + CodeBuild로 웹후크 페이로드를 전송할 개별 이벤트를 구성합니다. **트리거**에서 **푸시 이벤트**, **병합 요청 이벤트**. **릴리스 이벤트**, **작업 이벤트** 중에서 선택합니다. CodeBuild에서 지원하는 이벤트 유형에 대한 자세한 내용은 [GitLab 웹후크 이벤트](gitlab-webhook.md) 섹션을 참조하세요.

1. **웹후크 추가**를 선택합니다.

# GitLab 웹후크 이벤트
<a name="gitlab-webhook"></a>

웹후크 필터 그룹을 사용하여 어느 GitLab 웹후크 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 예를 들어 특정 분기가 변경된 경우에만 빌드가 트리거되도록 지정할 수 있습니다.

하나 이상의 웹후크 필터 그룹을 생성하여 어느 웹후크 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 필터 그룹이 true로 평가(그룹 내 모든 필터가 true로 평가)되면 빌드가 트리거됩니다. 필터 그룹을 생성할 때 다음을 지정합니다.

**이벤트**  
GitLab의 경우 `PUSH`, `PULL_REQUEST_CREATED`, `PULL_REQUEST_UPDATED`, `PULL_REQUEST_MERGED`, `PULL_REQUEST_REOPENED`, `PULL_REQUEST_CLOSED`, `RELEASED` 및 `WORKFLOW_JOB_QUEUED` 이벤트 가운데 하나 이상을 선택할 수 있습니다.  
webhook의 이벤트 유형은 `X-GitLab-Event` 필드의 헤더에 있습니다. 다음 표에서는 `X-GitLab-Event` 헤더 값이 이벤트 유형에 매핑되는 방법을 보여 줍니다. `Merge Request Hook` 웹후크 이벤트의 경우 페이로드의 `object_atttributes.action`에는 병합 요청 유형에 대한 추가 정보가 포함됩니다.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/gitlab-webhook.html)
`PULL_REQUEST_MERGED`의 경우 풀 요청이 스쿼시 전략에 병합되고 풀 요청 분기가 닫히면 원래의 풀 요청 커밋은 더 이상 존재하지 않게 됩니다. 이 경우 `CODEBUILD_WEBHOOK_MERGE_COMMIT` 환경 변수에는 스쿼시된 병합 커밋의 식별자가 포함됩니다.

**하나 이상의 선택적 필터**  
정규식을 사용하여 필터를 지정합니다. 이벤트가 빌드를 트리거하려면 연결된 그룹 내의 필터가 모두 true로 평가되어야 합니다.    
`ACTOR_ACCOUNT_ID`(콘솔의 `ACTOR_ID`)  
GitLab 계정 ID가 정규식 패턴과 일치하면 웹후크 이벤트가 빌드를 트리거합니다. Webhook 필터 페이로드에 있는 `actor` 객체의 `account_id` 속성에 이 값이 표시됩니다.  
`HEAD_REF`  
헤드 참조가 정규식 패턴(예: `refs/heads/branch-name` 및 `refs/tags/tag-name`)과 일치하면 webhook 이벤트가 빌드를 트리거합니다. `HEAD_REF` 필터가 브랜치나 태그의 Git 참조 이름을 평가합니다. Webhook 페이로드의 `push` 객체에 있는 `new` 객체의 `name` 필드에 브랜치 또는 태그 이름이 표시됩니다. pull 요청 이벤트의 경우 webhook 페이로드의 `source` 객체에 있는 `branch` 객체의 `name` 필드에 브랜치 이름이 표시됩니다.  
`BASE_REF`  
베이스 참조가 정규식 패턴과 일치하면 webhook 이벤트가 빌드를 트리거합니다. `BASE_REF` 필터는 풀 요청 이벤트에서만 작동합니다(예: `refs/heads/branch-name`). `BASE_REF` 필터가 브랜치의 Git 참조 이름을 평가합니다. Webhook 페이로드의 `destination` 객체에 있는 `branch` 객체의 `name` 필드에 브랜치 이름이 표시됩니다.  
`FILE_PATH`  
변경된 파일의 경로가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다.  
`COMMIT_MESSAGE`  
헤드 커밋 메시지가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다.  
`WORKFLOW_NAME`  
워크플로 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다.

**참고**  
GitLab 리포지토리의 웹후크 설정에서 웹후크 페이로드를 찾을 수 있습니다.

**Topics**
+ [GitLab 웹후크 이벤트 필터링(콘솔)](gitlab-webhook-events-console.md)
+ [GitLab 웹후크 이벤트 필터링(SDK)](gitlab-webhook-events-sdk.md)
+ [GitLab 웹후크 이벤트 필터링(CloudFormation)](gitlab-webhook-events-cfn.md)

# GitLab 웹후크 이벤트 필터링(콘솔)
<a name="gitlab-webhook-events-console"></a>

다음 지침에 따라를 사용하여 웹후크 이벤트를 필터링 AWS Management Console 합니다. GitLab 웹후크 이벤트에 대한 자세한 내용은 [GitLab 웹후크 이벤트](gitlab-webhook.md) 섹션을 참조하세요.

1.  프로젝트를 생성할 때 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.

1.  **이벤트 유형**에서 하나 이상의 이벤트를 선택합니다.

1.  이벤트가 빌드를 트리거할 때를 필터링하려면 **Start a build under these conditions(다음 조건에서 빌드를 시작)**에서 하나 이상의 선택적 필터를 추가합니다.

1.  이벤트가 트리거되지 않을 때를 필터링하려면 **Don't start a build under these conditions(다음 조건에서 빌드를 시작하지 않음)**에서 하나 이상의 선택적 필터를 추가합니다.

1.  **Add filter group(필터 그룹 추가)**를 선택하여 다른 필터 그룹을 추가합니다.

 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 *AWS CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.

이 예제에서는 Webhook 필터 그룹이 pull 요청에 대해서만 빌드를 트리거합니다.

![\[pull 요청에 대해서만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-gitlab.png)


두 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/branch1!`와 일치하는 헤드 참조를 갖는 브랜치에서 생성 또는 업데이트된 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/branch1$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.

![\[두 필터 그룹의 예입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes-gitlab.png)


이 예제에서는 Webhook 필터 그룹이 태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거합니다.

![\[태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude-gitlab.png)


이 예제에서는 Webhook 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드를 트리거합니다.

![\[파일이 지정된 정규식과 일치하는 이름을 갖는 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex-gitlab.png)


이 예제에서 Webhook 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경된 경우에만 빌드를 트리거합니다.

![\[파일이 지정된 폴더에서 변경된 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex-gitlab.png)


이 예제에서는 웹후크 필터 그룹이 정규식 `actor-account-id`와 일치하는 계정 ID가 없는 GitLab 사용자가 변경을 수행한 경우에만 빌드를 트리거합니다.

**참고**  
 GitLab 계정 ID를 확인하는 자세한 방법은 https://api.github.com/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 GitLab 사용자 이름입니다.

![\[계정 ID가 없는 GitLab 사용자가 변경한 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-actor-gitlab.png)


이 예제에서 webhook 필터 그룹은 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때 푸시 이벤트에 대한 빌드를 트리거합니다.

![\[헤드 커밋 메시지가 정규식과 일치할 때 푸시 이벤트에 대한 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message-gitlab.png)


# GitLab 웹후크 이벤트 필터링(SDK)
<a name="gitlab-webhook-events-sdk"></a>

 AWS CodeBuild SDK를 사용하여 웹후크 이벤트를 필터링하려면 `CreateWebhook` 또는 `UpdateWebhook` API 메서드의 요청 구문에서 `filterGroups` 필드를 사용합니다. 자세한 내용은 *CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.

GitLab 웹후크 이벤트에 대한 자세한 내용은 [GitLab 웹후크 이벤트](gitlab-webhook.md) 섹션을 참조하세요.

 pull 요청에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 요청 구문에 다음을 삽입합니다.

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
    }
  ]
]
```

 지정된 브랜치에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 `pattern` 파라미터를 사용하여 브랜치 이름을 필터링하는 정규식을 지정합니다. 두 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/myBranch$`와 일치하는 헤드 참조를 갖는 브랜치에서 생성 또는 업데이트된 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/myBranch$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED"
    },
    {
      "type": "HEAD_REF",
      "pattern": "^refs/heads/myBranch$"
    },
    {
      "type": "BASE_REF",
      "pattern": "^refs/heads/main$"
    }
  ],
  [
    {
      "type": "EVENT",
      "pattern": "PUSH"
    },
    {
      "type": "HEAD_REF",
      "pattern": "^refs/heads/myBranch$"
    }
  ]
]
```

 `excludeMatchedPattern` 파라미터를 사용하여 빌드를 트리거하지 않을 이벤트를 지정할 수 있습니다. 이 예제에서는 태그 이벤트를 제외한 모든 요청에 대해 빌드가 트리거됩니다.

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
    },
    {
      "type": "HEAD_REF",
      "pattern": "^refs/tags/.*",
      "excludeMatchedPattern": true
    }
  ]
]
```

계정 ID가 `actor-account-id`인 GitLab 사용자가 변경을 수행한 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다.

**참고**  
 GitLab 계정 ID를 확인하는 자세한 방법은 https://api.github.com/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 GitLab 사용자 이름입니다.

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
    },
    {
      "type": "ACTOR_ACCOUNT_ID",
      "pattern": "actor-account-id"
    }
  ]
]
```

`pattern` 인수의 정규식과 일치하는 이름을 갖는 파일이 변경되는 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서는 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드가 트리거되도록 지정합니다.

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PUSH"
    },
    {
      "type": "FILE_PATH",
      "pattern": "^buildspec.*"
    }
  ]
]
```

이 예제에서 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경될 때만 빌드가 트리거되도록 지정합니다.

```
"filterGroups": [
    [
        {
            "type": "EVENT", 
            "pattern": "PUSH"
        },
        {
            "type": "FILE_PATH", 
            "pattern": "^src/.+|^test/.+"
        }
    ]
]
```

헤드 커밋 메시지가 패턴 인수의 정규식과 일치할 때만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서 필터 그룹은 푸시 이벤트의 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때만 빌드가 트리거되도록 지정합니다.

```
  "filterGroups": [
    [
      {
        "type": "EVENT",
        "pattern": "PUSH"
      },
      {
        "type": "COMMIT_MESSAGE",
        "pattern": "\[CodeBuild\]"
      }
    ]
  ]
```

# GitLab 웹후크 이벤트 필터링(CloudFormation)
<a name="gitlab-webhook-events-cfn"></a>

 CloudFormation 템플릿을 사용하여 웹후크 이벤트를 필터링하려면 AWS CodeBuild 프로젝트의 `FilterGroups` 속성을 사용합니다. GitLab 웹후크 이벤트에 대한 자세한 내용은 [GitLab 웹후크 이벤트](gitlab-webhook.md) 섹션을 참조하세요.

다음 CloudFormation 템플릿의 YAML 형식 부분은 두 개의 필터 그룹을 생성합니다. 이들은 하나 또는 둘 모두 true로 평가되면 빌드를 트리거합니다.
+  첫 번째 필터 그룹은 계정 ID가 `12345`와 일치하지 않는 GitLab 사용자가 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름을 갖는 분기에서 생성 또는 업데이트한 pull 요청을 지정합니다.
+  두 번째 필터 그룹은 정규식 `^refs/heads/.*`와 일치하는 Git 참조 이름을 갖는 브랜치에서 생성되는 push 요청을 지정합니다.
+ 세 번째 필터 그룹은 정규식 `\[CodeBuild\]`와 일치하는 헤드 커밋 메시지에서 push 요청을 지정합니다.
+ 네 번째 필터 그룹은 정규식 `\[CI-CodeBuild\]`와 일치하는 워크플로 이름을 가진 GitHub Action 워크플로 작업 요청을 지정합니다.

```
CodeBuildProject:
  Type: AWS::CodeBuild::Project
  Properties:
    Name: MyProject
    ServiceRole: service-role
    Artifacts:
      Type: NO_ARTIFACTS
    Environment:
      Type: LINUX_CONTAINER
      ComputeType: BUILD_GENERAL1_SMALL
      Image: aws/codebuild/standard:5.0
    Source:
      Type: GITLAB
      Location: source-location
    Triggers:
      Webhook: true
      FilterGroups:
        - - Type: EVENT
            Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
          - Type: BASE_REF
            Pattern: ^refs/heads/main$
            ExcludeMatchedPattern: false
          - Type: ACTOR_ACCOUNT_ID
            Pattern: 12345
            ExcludeMatchedPattern: true
        - - Type: EVENT
            Pattern: PUSH
          - Type: HEAD_REF
            Pattern: ^refs/heads/.*
        - - Type: EVENT
            Pattern: PUSH
          - Type: COMMIT_MESSAGE
            Pattern: \[CodeBuild\]
        - - Type: EVENT
            Pattern: WORKFLOW_JOB_QUEUED
          - Type: WORKFLOW_NAME
            Pattern: \[CI-CodeBuild\]
```

# Buildkite 수동 웹후크
<a name="buildkite-manual-webhook"></a>

현재 CodeBuild에서는 모든 Buildkite 웹후크를 수동으로 생성해야 합니다. CodeBuild는 직접 호출의 일부로 페이로드 URL을 반환하여 웹후크를 생성합니다. 이 URL은 Buildkite 내에서 수동으로 웹후크를 생성하는 데 사용할 수 있습니다.

다음 절차에 따라 Buildkite 수동 웹후크를 생성합니다.

**웹후크를 사용하여 CodeBuild 프로젝트를 생성하려면**

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)에서 AWS CodeBuild 콘솔을 엽니다.

1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.

1. **프로젝트 구성**에서 **실행기 프로젝트**를 선택합니다.

   **실행기**에서:
   + **실행기 공급자**에서 **Buildkite**를 선택합니다.
   + **Buildkite 에이전트 토큰**에서 **보안 암호 생성 페이지를 사용하여 새 에이전트 토큰 생성**을 선택합니다. AWS Secrets Manager에서 앞서 생성한 Buildkite 에이전트 토큰과 동일한 보안 암호 값을 가진 새 보안 암호를 생성하라는 메시지가 표시됩니다.
   + (선택 사항) 작업에 CodeBuild 관리형 자격 증명을 사용하려면 **Buildkite 소스 자격 증명 옵션**에서 작업의 소스 리포지토리 공급자를 선택하고 자격 증명이 계정에 대해 구성되어 있는지 확인합니다. 또한, Buildkite 파이프라인이 **HTTPS를 사용한 체크아웃**을 사용하는지 확인합니다.

1. 
   +  **환경**에서 다음과 같이 합니다.
     + 지원되는 **환경 이미지**와 **컴퓨팅**을 선택합니다. GitHub Action 워크플로 YAML의 레이블을 사용하여 이미지 및 인스턴스 설정을 재정의할 수 있는 옵션이 있습니다. 자세한 내용은 [2단계: GitHub Action 워크플로 YAML 업데이트](action-runner.md#sample-github-action-runners-update-yaml) 섹션을 참조하세요.
   +  **Buildspec**에서 다음과 같이 합니다.
     + `buildspec-override:true`가 레이블로 추가되지 않는 한 buildspec은 무시됩니다. 대신 CodeBuild는 자체 호스팅 실행기를 설정하는 명령을 사용하도록 재정의합니다.

1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다.

1. **웹후크 생성** 팝업에서 **페이로드 URL** 및 **보안 암호** 값을 저장합니다. 팝업의 지침에 따라 새 Buildkite 조직 웹후크를 생성합니다.

# 풀 요청 설명 승인
<a name="pull-request-build-policy"></a>

CodeBuild는 풀 요청에 의해 트리거되는 빌드에 대한 추가 제어를 제공하는 풀 요청 빌드 정책을 지원합니다. 변경 사항을 검토할 수 있을 때까지 알 수 없는 사용자의 풀 요청을 자동으로 빌드하지 않을 수 있습니다. 이 기능을 사용하면 팀원 중 한 명이 먼저 코드를 검토한 다음 파이프라인을 실행하도록 요구할 수 있습니다. 이는 일반적으로 알 수 없는 기여자가 제출한 코드를 빌드할 때 보안 조치로 사용됩니다.

풀 요청 빌드 정책을 사용하면 CodeBuild가 기여자의 권한 및 승인 상태에 따라 풀 요청에 대한 빌드를 트리거하는 시기를 제어할 수 있습니다. 이는 퍼블릭 리포지토리 또는 외부 공동 작업자의 기여를 수락하는 리포지토리에 특히 중요합니다.

이 기능을 활성화하면 다음 중 하나에 해당하는 경우에만 풀 요청에 대해 빌드가 트리거됩니다.
+ 풀 요청이 신뢰할 수 있는 기여자에 의해 생성됩니다.
+ 신뢰할 수 있는 기여자가 특정 설명을 게시하여 풀 요청을 승인합니다.

## 작동 방식
<a name="pull-request-build-policy.how-it-works"></a>

**신뢰할 수 있는 기여자**  
신뢰할 수 있는 기여자는 소스 제어 시스템의 현재 역할이 풀 요청 기반 정책에서 승인자 역할로 설정된 사용자입니다. 신뢰할 수 있는 기여자가 풀 요청을 생성하면 CodeBuild는 빌드를 자동으로 트리거하여 현재 동작을 유지합니다.

**신뢰할 수 없는 기여자**  
신뢰할 수 없는 기여자는 승인자 역할 목록에 역할이 설정되지 않은 사용자입니다. 신뢰할 수 없는 기여자가 풀 요청을 생성하는 경우:  

1. CodeBuild는 '빌드를 시작하는 데 풀 요청 승인 필요'라는 메시지와 함께 빌드 상태를 '실패'로 표시합니다.

1. 신뢰할 수 있는 기여자는 변경 사항을 검토하고 `/codebuild_run(<SHA_OF_THE_LATEST_COMMIT>)`과 함께 설명을 게시하여 빌드를 트리거해야 합니다. 예를 들어 `/codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369)`입니다.

1. CodeBuild는 해설자의 권한을 검증하고 승인된 경우 빌드를 트리거합니다.

1. 빌드 결과는 풀 요청 페이지에 다시 보고됩니다.

**설명 승인 구문**  
신뢰할 수 있는 기여자는 다음 설명 형식을 사용하여 빌드를 승인할 수 있습니다.  
+ `/codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369)` - 지정된 커밋 SHA에서 빌드를 트리거합니다.

## 구성
<a name="pull-request-build-policy.configuration"></a>

**기본 동작**  
풀 요청 빌드 정책은 새로 생성된 모든 CodeBuild 프로젝트에 대해 기본적으로 활성화됩니다.

**API 파라미터**  
풀 요청 빌드 정책은 다음 작업의 `PullRequestBuildPolicy` 파라미터를 사용하여 구성됩니다.  
+ `CreateWebhook`
+ `UpdateWebhook`

**`PullRequestBuildPolicy` 구조**  

```
{
    "requiresCommentApproval": "string",
    "approverRoles": ["string", ...]
}
```

**`requiresCommentApproval`**  
풀 요청에 대한 빌드를 트리거하기 전에 설명 기반 승인이 필요한 시기를 지정합니다. 이 설정은 빌드가 자동으로 실행되는지, 아니면 설명을 통한 명시적 승인이 필요한지를 결정합니다.  
유형: 문자열  
유효한 값:  
+ `DISABLED` - 설명 승인 없이 트리거를 자동으로 빌드합니다.
+ `FORK_PULL_REQUESTS` - 포크된 리포지토리의 풀 요청만 설명 승인이 필요합니다(기여자가 승인자 역할 중 하나가 아닌 경우).
+ `ALL_PULL_REQUESTS` - 모든 풀 요청은 빌드를 실행하기 전에 설명 승인이 필요합니다(기여자가 승인자 역할 중 하나가 아닌 경우). 이것이 기본값입니다.

**`approverRoles`**  
설명 승인이 필요한 경우 풀 요청 빌드에 대한 승인 권한이 있는 리포지토리 역할 목록입니다. 이러한 역할을 가진 사용자만 유효한 설명 승인을 제공할 수 있습니다. 풀 요청 기여자가 이러한 역할 중 하나인 경우 풀 요청 빌드가 자동으로 트리거됩니다.  
유형: 문자열 배열  
GitHub 프로젝트의 유효한 값(값은 GitHub 역할에 매핑됨):  
+ `GITHUB_ADMIN` - 리포지토리 관리자
+ `GITHUB_MAINTAIN` - 리포지토리 유지 관리자
+ `GITHUB_WRITE` - 쓰기 권한이 있는 사용자
+ `GITHUB_TRIAGE` - 분류 권한이 있는 사용자
+ `GITHUB_READ` - 읽기 권한이 있는 사용자
+ 기본값: `["GITHUB_ADMIN", "GITHUB_MAINTAINER", "GITHUB_WRITE"]`
GitLab 프로젝트의 유효한 값(값은 GitLab 역할에 매핑됨):  
+ `GITLAB_OWNER` - 리포지토리 소유자
+ `GITLAB_MAINTAINER` - 리포지토리 유지 관리자
+ `GITLAB_DEVELOPER` - 개발자 권한이 있는 사용자
+ `GITLAB_REPORTER` - 보고자 권한이 있는 사용자
+ `GITLAB_PLANNER` - 기획자 권한이 있는 사용자
+ `GITLAB_GUEST ` - 게스트 권한이 있는 사용자
+ 기본값: `["GITLAB_OWNER", "GITLAB_MAINTAINER", "GITLAB_DEVELOPER"]`
Bitbucket 프로젝트의 유효한 값(값은 Bitbucket 역할에 매핑됨):  
+ `BITBUCKET_ADMIN ` - 리포지토리 관리자
+ `BITBUCKET_WRITE` - 쓰기 권한이 있는 사용자
+ `BITBUCKET_READ ` - 읽기 권한이 있는 사용자
+ 기본값: `["BITBUCKET_ADMIN", "BITBUCKET_WRITE"]`

## 예제
<a name="pull-request-build-policy.examples"></a>

**모든 풀 요청에 대한 설명 승인 활성화**  
 AWS CodeBuild SDK를 사용하여 웹후크에 대한 풀 요청 빌드 정책을 활성화하거나 비활성화하려면 `CreateWebhook` 또는 `UpdateWebhook` API 메서드의 요청 구문에서 `pullRequestBuildPolicy` 필드를 사용합니다. 자세한 내용은 *CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.  
GitHub에서 관리, 유지 관리 및 쓰기 역할을 가진 사용자는 신뢰할 수 있는 기여자로 처리됩니다.  

```
"pullRequestBuildPolicy": {
    "requiresCommentApproval": "ALL_PULL_REQUESTS",
    "approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAIN", "GITHUB_WRITE"]
}
```

**리포지토리 관리자 및 유지 관리자에 대해서만 설명 승인 활성화**  
GitHub에서 관리, 유지 관리 역할을 가진 사용자는 신뢰할 수 있는 기여자로 처리됩니다.  

```
"pullRequestBuildPolicy": {
    "requiresCommentApproval": "FORK_PULL_REQUESTS",
    "approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAINER"]
}
```

**설명 승인 비활성화**  

```
"pullRequestBuildPolicy": { 
    "requiresCommentApproval": "DISABLED"
}
```

## AWS CloudFormation
<a name="pull-request-build-policy.cloudformation"></a>

 AWS CloudFormation 템플릿을 사용하여 웹후크에 대한 풀 요청 빌드 정책을 활성화하거나 비활성화하려면 PullRequestBuildPolicy 속성을 사용합니다. AWS CloudFormation 템플릿의 다음 YAML 형식 부분은 모든 풀 요청에 대해 풀 요청 빌드 정책이 활성화된 웹후크가 있는 프로젝트를 생성합니다. 유지 관리 및 관리 역할은 승인자로 지정됩니다.

```
CodeBuildProject:
  Type: AWS::CodeBuild::Project
  Properties:
    Name: MyProject
    ServiceRole: service-role
    Artifacts:
      Type: NO_ARTIFACTS
    Environment:
      Type: LINUX_CONTAINER
      ComputeType: BUILD_GENERAL1_SMALL
      Image: aws/codebuild/standard:5.0
    Source:
      Type: BITBUCKET
      Location: source-location
    Triggers:
      Webhook: true
      FilterGroups:
        - - Type: EVENT
            Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
          - Type: BASE_REF
            Pattern: ^refs/heads/main$
            ExcludeMatchedPattern: false
      PullRequestBuildPolicy:
        RequiresCommentApproval: ALL_PULL_REQUESTS
        ApproverRoles:
          - GITHUB_MAINTAIN
          - GITHUB_ADMIN
```

## 콘솔 구성
<a name="pull-request-build-policy.console"></a>

 AWS 관리 콘솔을 사용하여 웹후크 이벤트를 필터링하려면:

1. **설명 승인**에서 모든 풀 요청(`ALL_PULL_REQUEST`)에 대해 비활성화 또는 활성화를 선택하거나 포크의 풀 요청(`FORK_PULL_REQUEST`)에 대해서만 비활성화 또는 활성화를 선택합니다.

1. **승인자 역할**에서 설명 승인이 필요할 때 풀 요청 빌드에 대한 승인 권한이 있는 리포지토리 역할을 선택합니다.

자세한 내용은 *CodeBuild API 참조*의 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.

![\[설명 승인이 있는 기본 소스 웹후크 이벤트 콘솔입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-comment-approval.png)


# 에서 빌드 프로젝트의 세부 정보 보기 AWS CodeBuild
<a name="view-project-details"></a>

 AWS CodeBuild 콘솔 AWS CLI, 또는 AWS SDKs를 사용하여 CodeBuild에서 빌드 프로젝트의 세부 정보를 볼 수 있습니다.

**Topics**
+ [빌드 프로젝트 세부 정보 보기(콘솔)](#view-project-details-console)
+ [빌드 프로젝트 세부 정보 보기(AWS CLI)](#view-project-details-cli)
+ [빌드 프로젝트의 세부 정보(AWS SDKs) 보기](#view-project-details-sdks)

## 빌드 프로젝트 세부 정보 보기(콘솔)
<a name="view-project-details-console"></a>

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.

1. 탐색 창에서 **프로젝트 빌드**를 선택합니다.
**참고**  
기본적으로 가장 최근의 빌드 프로젝트 10개만 표시됩니다. 더 많은 빌드 프로젝트를 보려면 기어 아이콘을 선택하고 **페이지당 프로젝트 수**에서 다른 값을 선택하거나 뒤로 및 앞으로 화살표를 사용합니다.

1. 빌드 프로젝트 목록의 **이름** 열에서 빌드 프로젝트에 대한 링크를 선택합니다.

1. **프로젝트 빌드: *project-name*** 페이지에서 **빌드 세부 정보**를 선택합니다.

## 빌드 프로젝트 세부 정보 보기(AWS CLI)
<a name="view-project-details-cli"></a>



**batch-get-projects** 명령을 실행합니다.

```
aws codebuild batch-get-projects --names names
```

이전 명령에서 다음 자리표시자를 바꿉니다.
+ *names*: 세부 정보를 볼 수 있는 하나 이상의 빌드 프로젝트 이름을 나타내는 데 사용되는 필수 문자열입니다. 둘 이상의 빌드 프로젝트를 지정하려면 각 빌드 프로젝트 이름을 공백을 사용하여 구분해야 합니다. 최대 100개의 빌드 프로젝트 이름을 지정할 수 있습니다. 빌드 프로젝트 목록을 가져오려면 [빌드 프로젝트 이름 목록 보기(AWS CLI)](view-project-list.md#view-project-list-cli) 단원을 참조하십시오.

예를 들면 다음 명령을 실행하는 경우

```
aws codebuild batch-get-projects --names codebuild-demo-project codebuild-demo-project2 my-other-demo-project
```

다음과 비슷한 결과가 출력에 나타납니다. 줄임표(`...`)는 간결성을 위해 생략된 데이터를 나타내는 데 사용됩니다.

```
{
  "projectsNotFound": [
    "my-other-demo-project"
  ],
  "projects": [
    {
      ...
      "name": codebuild-demo-project,
      ...
    },
    {
      ...
      "name": codebuild-demo-project2",
      ...
    }
  ]
}
```

위 출력에서 `projectsNotFound` 배열에는 지정되었지만 찾을 수 없는 모든 빌드 프로젝트 이름이 나열됩니다. `projects` 배열에는 정보가 발견된 각 빌드 프로젝트의 세부 정보가 나열됩니다. 간결성을 위해 이전 출력에서 빌드 프로젝트 세부 정보가 생략되었습니다. 자세한 내용은 [빌드 프로젝트 생성(AWS CLI)](create-project.md#create-project-cli)의 출력을 참조하세요.

**batch-get-projects** 명령은 특정 속성 값에 대한 필터링을 지원하지 않지만 프로젝트의 속성을 열거하는 스크립트를 작성할 수 있습니다. 예를 들어, 다음 Linux 쉘 스크립트는 현재 계정의 현재 리전에 있는 프로젝트를 열거하고 각 프로젝트에서 사용되는 이미지를 인쇄합니다.

```
#!/usr/bin/sh

# This script enumerates all of the projects for the current account 
# in the current region and prints out the image that each project is using.

imageName=""

function getImageName(){
  local environmentValues=(${1//$'\t'/ })
  imageName=${environmentValues[1]}
}

function processProjectInfo() {
  local projectInfo=$1

  while IFS=$'\t' read -r section value; do
    if [[ "$section" == *"ENVIRONMENT"* ]]; then
      getImageName "$value"
    fi
  done <<< "$projectInfo"
}

# Get the list of projects.
projectList=$(aws codebuild list-projects --output=text)

for projectName in $projectList
do
  if [[ "$projectName" != *"PROJECTS"* ]]; then
    echo "==============================================="

    # Get the detailed information for the project.
    projectInfo=$(aws codebuild batch-get-projects --output=text --names "$projectName")

    processProjectInfo "$projectInfo"

    printf 'Project "%s" has image "%s"\n' "$projectName" "$imageName"
  fi
done
```

와 AWS CLI 함께를 사용하는 방법에 대한 자세한 내용은 단원을 AWS CodeBuild참조하십시오[명령줄 참조](cmd-ref.md).

## 빌드 프로젝트의 세부 정보(AWS SDKs) 보기
<a name="view-project-details-sdks"></a>

를 SDK와 AWS CodeBuild 함께 사용하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS SDKs 및 도구 참조](sdk-ref.md). AWS SDKs

# 에서 빌드 프로젝트 이름 보기 AWS CodeBuild
<a name="view-project-list"></a>

 AWS CodeBuild 콘솔 AWS CLI, 또는 AWS SDKs 사용하여 CodeBuild의 빌드 프로젝트 목록을 볼 수 있습니다.

**Topics**
+ [빌드 프로젝트 이름 목록 보기(콘솔)](#view-project-list-console)
+ [빌드 프로젝트 이름 목록 보기(AWS CLI)](#view-project-list-cli)
+ [빌드 프로젝트 이름(AWS SDKs) 목록 보기](#view-project-list-sdks)

## 빌드 프로젝트 이름 목록 보기(콘솔)
<a name="view-project-list-console"></a>

콘솔에서 AWS 리전의 빌드 프로젝트 목록을 볼 수 있습니다. 정보에는 이름, 소스 공급자, 리포지토리, 최신 빌드 상태 및 설명(있는 경우)이 포함됩니다.

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.

1. 탐색 창에서 **프로젝트 빌드**를 선택합니다.
**참고**  
기본적으로 가장 최근의 빌드 프로젝트 10개만 표시됩니다. 더 많은 빌드 프로젝트를 보려면 기어 아이콘을 선택하고 **페이지당 프로젝트 수**에서 다른 값을 선택하거나 뒤로 및 앞으로 화살표를 사용합니다.

## 빌드 프로젝트 이름 목록 보기(AWS CLI)
<a name="view-project-list-cli"></a>

**list-projects** 명령을 실행합니다.

```
aws codebuild list-projects --sort-by sort-by --sort-order sort-order --next-token next-token
```

이전 명령에서 다음 자리표시자를 바꿉니다.
+ *sort-by*: 빌드 프로젝트 이름을 나열하는 데 사용할 기준을 나타내는 데 사용되는 선택적 문자열입니다. 유효한 값으로는 다음이 포함됩니다.
  + `CREATED_TIME`: 각 빌드 프로젝트가 생성된 시기를 기준으로 빌드 프로젝트 이름을 나열합니다.
  + `LAST_MODIFIED_TIME`: 각 빌드 프로젝트에 대한 정보가 마지막으로 변경된 시기를 기준으로 빌드 프로젝트 이름을 나열합니다.
  + `NAME`: 각 빌드 프로젝트의 이름을 기준으로 빌드 프로젝트 이름을 나열합니다.
+ *sort-order*: *sort-by*에 따라 빌드 프로젝트를 나열하는 순서를 나타내는 데 사용되는 선택적 문자열입니다. 유효한 값에는 `ASCENDING` 및 `DESCENDING`(이)가 있습니다.
+ *next-token*: 선택적 문자열입니다. 이전 실행 중에 목록에 100개가 넘는 항목이 있는 경우 *next token*이라는 고유한 문자열과 함께 처음 100개 항목만 반환됩니다. 목록에서 다음 항목 배치를 가져오려면 호출에 다음 토큰을 추가하여 이 명령을 다시 실행합니다. 목록에 있는 모든 항목을 가져오려면 다음 토큰이 더 이상 반환되지 않을 때까지 다음 토큰마다 이 명령을 계속 실행합니다.

예를 들면 다음 명령을 실행하는 경우

```
aws codebuild list-projects --sort-by NAME --sort-order ASCENDING
```

다음과 비슷한 결과가 출력에 나타납니다.

```
{
  "nextToken": "Ci33ACF6...The full token has been omitted for brevity...U+AkMx8=",
  "projects": [
    "codebuild-demo-project",
    "codebuild-demo-project2",
    ... The full list of build project names has been omitted for brevity ...
    "codebuild-demo-project99"
  ]
}
```

이 명령을 다시 실행하는 경우:

```
aws codebuild list-projects  --sort-by NAME --sort-order ASCENDING --next-token Ci33ACF6...The full token has been omitted for brevity...U+AkMx8=
```

다음과 비슷한 결과가 출력에 나타납니다.

```
{
  "projects": [
    "codebuild-demo-project100",
    "codebuild-demo-project101",
    ... The full list of build project names has been omitted for brevity ...
    "codebuild-demo-project122"
  ]
}
```

## 빌드 프로젝트 이름(AWS SDKs) 목록 보기
<a name="view-project-list-sdks"></a>

를 SDK와 AWS CodeBuild 함께 사용하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS SDKs 및 도구 참조](sdk-ref.md). AWS SDKs